The links have a externalConfig term in their GunnsDraw shape data. More detail on that here.

Every fluid network must have exactly one Internal Fluid Config object, covered previously. They can also have zero or more External Fluid Config objects. An External Fluid Config is just like the Internal Fluid Config except it tells this network about the fluid types that are in an external network. You create one in the same way as an Internal Fluid Config except you select the External Fluid box in the Define Network Fluid Wizard. Every external supply & demand link uses one of these External Configs — it tells the link the order and types of the fluid in the information coming into this link from its external counterpart. Its external counterpart likewise uses an External config in its network that reflects the Internal config of this network. The link receiving the data is responsible for converting it into its local fluid config — the External fluid config is how it knows what to convert it from.

You need one External Fluid Config object in your drawing for every unique fluid configuration in external networks that links in this network need to interface with. A single External config object can be shared by multiple links in this network, as long as it represents whatever external network(s) they are interfacing with.

In the example picture above, the two networks have different fluid types in them. What happens when EclssFluid sends over some GUNNS_O2, but GUNNS_O2 is not in AtcsFluid? The receiving link can’t add GUNNS_O2 to its node because that fluid type doesn’t exist in AtcsFluid. It must convert to one or more of the types that it does have. Normally we try to avoid these situations because such “alchemy” isn’t realistic. However, there are times when a small amount of conversion is an acceptable limitation.

Other cases might be different fluid types that represent the same fluid compound such as GUNNS_O2 <—> GUNNS_O2_REAL_GAS. The only difference in these fluid types is the PVT state equation they implement, but they both represent the same O2 gas. The network that uses GUNNS_O2 (ideal gas) tends to operate at low pressures where O2 is ideal. The other network may store O2 in very high-pressure tanks where the Ideal Gas Law isn’t accurate, so it uses the more realistic GUNNS_O2_REAL_GAS. We can use the type conversion in the external supply/demand interface to handle the flows between them.

Conversion conserves moles, not mass. This is for stability between ideal gas networks at near-equal pressure, since a mole of any type of ideal gas increases pressure the same. When converting from one species to another, say O2 to N2, this doesn’t conserve total mass, because O2 and N2 have different molecular weights. But we figure if you’re willing to accept this unrealistic conversion of compounds, you can also live with not conserving the total mass.

Fluid types that are in both networks aren’t converted, and their mass is conserved in the interface.

There are two ways to do this conversion. Use the most appropriate for your interface:

Converts all of the incoming fluid types that don’t exist in the local network, to ONE of the fluid types that are in the local network.

Converts all of the incoming fluid types that don’t exist in the local network, to the current mixture of the local network fluid types that are in the interfacing node. In other words, it converts all of the incoming moles into more of the same mixture that is already in the receiving node.

Previous Page / Next Page