Abstract: One example discloses a test-point access structure within a semiconductor, including: a target test-point configured to be coupled to a circuit within the semiconductor; a first doped region within the semiconductor configured to generate a first signal in response to an energy beam transmitted by a circuit editing (CE) tool; a second doped region within the semiconductor configured to generate a second signal in response to the energy beam transmitted by the CE tool; and a target pad coupling the target test-point to the first doped region; wherein the CE tool is configured to remove material from the semiconductor in response to the first signal and the second signal.

Abstract: Implementations set forth herein relate to providing a subsidiary application GUI via a client interface. The GUI can be rendered when a user is accessing a first party system via an application that is provided by the first party or a separate entity. The subsidiary application GUI can be rendered in response to the user providing a search query to the first party server-such as a search query that is in furtherance of initializing receiving certain search results. The server can identify, based on the search query, one or more entities that offer primary and/or subsidiary applications, and request subsidiary data for visibly rendering corresponding subsidiary applications for each entity. The subsidiary applications can optionally provide access to application functions that would not otherwise be available at the client without a corresponding application being installed.

Abstract: Implementations set forth herein relate to providing a subsidiary application GUI via a client interface. The GUI can be rendered when a user is accessing a first party system via an application that is provided by the first party or a separate entity. The subsidiary application GUI can be rendered in response to the user providing a search query to the first party server—such as a search query that is in furtherance of initializing receiving certain search results. The server can identify, based on the search query, one or more entities that offer primary and/or subsidiary applications, and request subsidiary data for visibly rendering corresponding subsidiary applications for each entity. The subsidiary applications can optionally provide access to application functions that would not otherwise be available at the client without a corresponding application being installed.

Abstract: Implementations set forth herein relate to providing a subsidiary application GUI via a client interface. The GUI can be rendered when a user is accessing a first party system via an application that is provided by the first party or a separate entity. The subsidiary application GUI can be rendered in response to the user providing a search query to the first party server—such as a search query that is in furtherance of initializing receiving certain search results. The server can identify, based on the search query, one or more entities that offer primary and/or subsidiary applications, and request subsidiary data for visibly rendering corresponding subsidiary applications for each entity. The subsidiary applications can optionally provide access to application functions that would not otherwise be available at the client without a corresponding application being installed.

Abstract: Implementations set forth herein relate to providing a subsidiary application GUI via a client interface. The GUI can be rendered when a user is accessing a first party system via an application that is provided by the first party or a separate entity. The subsidiary application GUI can be rendered in response to the user providing a search query to the first party server—such as a search query that is in furtherance of initializing receiving certain search results. The server can identify, based on the search query, one or more entities that offer primary and/or subsidiary applications, and request subsidiary data for visibly rendering corresponding subsidiary applications for each entity. The subsidiary applications can optionally provide access to application functions that would not otherwise be available at the client without a corresponding application being installed.

Abstract: Implementations set forth herein relate to providing a subsidiary application GUI via a client interface. The GUI can be rendered when a user is accessing a first party system via an application that is provided by the first party or a separate entity. The subsidiary application GUI can be rendered in response to the user providing a search query to the first party server—such as a search query that is in furtherance of initializing receiving certain search results. The server can identify, based on the search query, one or more entities that offer primary and/or subsidiary applications, and request subsidiary data for visibly rendering corresponding subsidiary applications for each entity. The subsidiary applications can optionally provide access to application functions that would not otherwise be available at the client without a corresponding application being installed.

Abstract: The present teachings include a power generation system for recovering waste heat energy from a power plant having a coolant circuit that extends through the power plant. The coolant circuit may also include a radiator and a coolant pump configured to circulate the coolant between the internal combustion engine and the radiator. The power generation system may also include a waste heat recovery circuit including a Roots-type fluid expander configured to generate power at an output shaft by expanding a portion of the coolant and being configured to deliver the power back to the internal combustion engine crankshaft via the output shaft. The waste heat recovery circuit may further include a circulation pump configured to circulate coolant between the Roots-type expander and the coolant circuit. A condenser may also be provided to condense the coolant leaving the Roots-type fluid expander at least down to a saturated liquid.

Abstract: A gear pump unit for hydroelectric power generation comprises a generator (138) and a control module operatively connected to a gear pump (131). The gear pump (131) comprises a case (131B) with a fluid inlet (132) and an outlet (135). A first rotor (133) comprises a first plurality of radially spaced teeth (133A, 133B, 133C) that wrap around the first rotor helically in a clockwise direction. A second rotor (134) comprises a second plurality of radially spaced teeth (134A, 134B, 134C) that wrap around the second rotor helically in a counter-clockwise direction. The first plurality of teeth mesh with the second plurality of teeth. The gear pump unit operates in a pump, turbine, or siphon mode via the control module 150 selectively rotating the first and second rotors. Electricity is generated by coupling the rotational energy of the first and second rotors to the generator (138).

Abstract: Techniques are described for performing automated predictions of program execution capacity or other capacity of computing-related hardware resources that will be used to execute software programs in the future, such as for a group of computing nodes that execute one or more programs for a user. The predictions that are performed may in at least some situations be based on historical data regarding corresponding prior actual usage of execution-related capacity (e.g., for one or more prior years), and may include long-term predictions for particular future time periods that are multiple months or years into the future. In addition, the predictions of the execution-related capacity for particular future time periods may be used in various manners, including to manage execution-related capacity at or before those future time periods, such as to prepare sufficient execution-related capacity to be available at those future time periods.

Abstract: Techniques are described for performing automated predictions of program execution capacity or other capacity of computing-related hardware resources that will be used to execute software programs in the future, such as for a group of computing nodes that execute one or more programs for a user. The predictions that are performed may in at least some situations be based on historical data regarding corresponding prior actual usage of execution-related capacity (e.g., for one or more prior years), and may include long-term predictions for particular future time periods that are multiple months or years into the future. In addition, the predictions of the execution-related capacity for particular future time periods may be used in various manners, including to manage execution-related capacity at or before those future time periods, such as to prepare sufficient execution-related capacity to be available at those future time periods.

Abstract: Techniques are described for performing automated predictions of program execution capacity or other capacity of computing-related hardware resources that will be used to execute software programs in the future, such as for a group of computing nodes that execute one or more programs for a user. The predictions that are performed may in at least some situations be based on historical data regarding corresponding prior actual usage of execution-related capacity (e.g., for one or more prior years), and may include long-term predictions for particular future time periods that are multiple months or years into the future. In addition, the predictions of the execution-related capacity for particular future time periods may be used in various manners, including to manage execution-related capacity at or before those future time periods, such as to prepare sufficient execution-related capacity to be available at those future time periods.

Abstract: Techniques are described for managing program execution capacity or other capacity of computing-related hardware resources used to execute software programs, such as for a group of computing nodes that is in use executing one or more programs for a user. Dynamic modifications to the program execution capacity of the group may include adding or removing computing nodes, such as in response to automated determinations that previously specified triggers are currently satisfied, and may be automatically governed at particular times based on automatically generated predictions of program execution capacity that will be used at those times by the group, such as to verify that requested dynamic execution capacity modifications at a time are within the predicted execution capacity values for that time. In some situations, the techniques are used in conjunction with a fee-based program execution service that executes multiple programs on behalf of multiple users of the service.

Abstract: Techniques are described for performing automated predictions of program execution capacity or other capacity of computing-related hardware resources that will be used to execute software programs in the future, such as for a group of computing nodes that execute one or more programs for a user. The predictions that are performed may in at least some situations be based on historical data regarding corresponding prior actual usage of execution-related capacity (e.g., for one or more prior years), and may include long-term predictions for particular future time periods that are multiple months or years into the future. In addition, the predictions of the execution-related capacity for particular future time periods may be used in various manners, including to manage execution-related capacity at or before those future time periods, such as to prepare sufficient execution-related capacity to be available at those future time periods.

Abstract: Techniques are described for managing program execution capacity or other capacity of computing-related hardware resources used to execute software programs, such as for a group of computing nodes that is in use executing one or more programs for a user. Dynamic modifications to the program execution capacity of the group may include adding or removing computing nodes, such as in response to automated determinations that previously specified triggers are currently satisfied, and may be automatically governed at particular times based on automatically generated predictions of program execution capacity that will be used at those times by the group, such as to verify that requested dynamic execution capacity modifications at a time are within the predicted execution capacity values for that time. In some situations, the techniques are used in conjunction with a fee-based program execution service that executes multiple programs on behalf of multiple users of the service.