Beginner help? None of the sims build.

[rmfranz13]

TLDR; I'm missing a file called "thread_safe_bus/thread_map.sm".

Hello, and apologies if this is the wrong forum for this type of question. I'm mostly just trying to get the attention of someone who knows what they're doing.

I'm working on a Trick project which suddenly found the need for simulating a complex fuel tank / feedline system (the NOVA-C). One of our ex-NASA folks suggested this project as a possible alternative to implementing our own, and I'm tasked with understanding whether we can use it and whether it meets our needs.

I'm hoping I'm free to use this, given it's released under the same license as Trick.

It'd be ideal if I could get a sim working to learn from, which ideally sets up and propagates some aspects of a tank system. Tracking pressures and mass flow rates is most important, and thermodynamic properties of gasses involved would also be nice but not essential.

My initial attempt was simply to set the GUNNS_HOME environment variable, and just trick-CP from anything under the "sims" folder. It looks like I'm missing a file called "thread_safe_bus/thread_map.sm"?

I also tried compiling from within the "gunns loaded and unloaed" docker containers, assuming they'd have the environment set up right, but I get the same error.

Thanks in advance for any guidance.

[rmfranz13]

Ah. Just realized there's a wiki. I should probably give that a read.

[jasonlharvey]

Hi Ryan, thanks for your feedback and yes, this is a good forum for answering your questions.

Yes, everyone is welcome to use GUNNS and Trick for free under the NASA open source license.

Unfortunately, the 'sim bus' code that generates the thread_safe_bus folder is not included in GUNNS and is not released, nor do we have plans to release it. Several of the sims in gunns/sims depend on it. SIM_test does not depend on it, so you should be able to build that sim, and it is a convenient sim to drop new models into.

More about the dependency in our wiki here: https://github.com/nasa/gunns/wiki/Introduction#limitations--dependencies More about the sim bus to give you an idea of what it's doing, in case you want to try to replicate it on your own: https://github.com/nasa/gunns/wiki/Sim_Bus_Users_Guide_for_GUNNS https://github.com/nasa/gunns/wiki/Fluid_Aspect_Course_3_1

The lack of the sim bus means you can't integrate networks together without adding your own 'glue code' to take its place. Lacking sim bus or a replacement, you can still run single networks, such as your tank/feedline system fluid network, in isolation.

I realize that not providing the sim bus really torpedos GUNNS' usefulness to outside users. I'd like to replace it with an improved system released in GUNNS someday, but I have no firm plans or timeframe on that.

[rmfranz13]

Thanks for the quick and very helpful response!

I am indeed able to build and run SIM_test/RUN_test, which gets my foot in the door.

I'm hoping the fact I can build and run SIM_test is somehow indicative that the underlying physical domains represented in the Test.sm are working on some level. Looks like it's modeling 3 separate physical networks: fluid, electrical, and thermal. My surface-level understanding of the sim bus is that, due to my lack of sim bus, these 3 networks are operating in isolation from one another, although each network itself is properly working in it's own little "universe"?

That scenario would likely be sufficient for our needs. We have an existing modeled tank system, but we're hoping GUNNS can provide a modeled "fluid network" representing the physics of our tank system, running along side our existing models, from which we can get/set pressure and temperature (if possible) readings. So the fluid network couldn't be totally isolated, but from reading the wiki link you sent, seems like that won't be the case. We'd be fine in setting up our own references/pointers.

I will be digging into the SIM_test on my own, but as I'm deciphering the code, I'm wondering what minimum models from GUNNS I'd need to set up a simple tank/feedline/valve system in a sim. Let's say for simplicity, I just want to model 1 tank that has a single valve that can be opened or closed. Is there a way to set this up purely with the model code, or do I need to utilize the diagram-drawing capability to create this? (very cool capability btw).

Thanks!

[jasonlharvey]

Glad to hear that SIM_test builds & runs for you. Yes each of those networks is running in isolation with no communication between them. They're all unrelated to each other and are just there to show that the 3 'flow aspects' are working.

We've built fluid networks for prop systems before, and have fluid properties for some common propellants. Yes you could build a fluid network of your system and get pressure & temperature sensor readings from it, and edit the fluid states in certain locations (the tanks, for example). I recommend going thru the basic & fluid tutorials to learn more about how to set up networks and interface to them here: https://github.com/nasa/gunns/wiki/Training_Courses. Also check out the link help pages here: https://github.com/nasa/gunns/wiki/Link_Help_Pages and for fluid: https://github.com/nasa/gunns/wiki/GunnsDraw-Fluid-Shapes-Library.

Here's a picture of about the simplest fluid network you could have for a liquid propellant. Use 'accumulator' links for liquid/ullage tanks, and GunnsFluidTank links for all gas tanks. I'm omitting some other necessary network stuff like the fluid config and initial states objects -- see the tutorial and fluid link help pages for more info:

You can write networks by hand, and you can see examples of what network C++ code looks like in gunns/sims/networks/fluid/test/TestFluidNetwork (this is auto-generated when you build SIM_test). But it's much easier to just do a GunnsDraw drawing for it, which then auto-generates the network code. That's covered in the tutorials, and more info about the Draw.io stuff here: https://github.com/nasa/gunns/wiki/GunnsDraw_Wiki_Start. I recommend taking a little extra time to install Draw.io and read up on how we use it, will save you a lot of time in the long run.

[rmfranz13]

Hey Jason, I really appreciate your help. We have a few more questions.

As a test, I was able to get the diagram you have above drawn and compiling with my sim (with added helium gas and cryogenic oxygen). I have a workflow now for working with the diagrams and getting them compiled. Given our example, I have member variables in my sim, such as myTestGunnsObject.myFluidNetwork.liquidPropUllageTank, which are accessible through the input file, and the sim runs without error while "myFluidNetwork" is updating. So off to a good start I think.

I showed my progress thus far to my team, and they had some questions I wasn't able to clearly answer for them. Hoping you can fill me in:

1. How can/should we initialize a fluid network through the input python files? We have many input.py files corresponding to different phases of our mission, each case therefore starting with varying amounts of fuel, at different temperatures etc. We'd much rather set these values in the input if possible.
2. How can we access sensor data and control valves through the input file? This could be user error on my part. I can see the sensors have methods, for instance, getPressure(), but all such methods return "0" for me.
3. We also noticed the accumulator object appears to have members intended for malfunction modeling, things like mMalfBellowsRupturePressRate. We'd like to know more about malfunction modeling in general in gunns, as it could save us work down the road.

Thanks again

[jasonlharvey]

1. Yes you can and should switch between different input files to set different initial conditions of the network. All the data that you set in the drawing (tank volume, valve conductivity, etc.) are the 'default' values that the network will start with if you don't override anything. They can all be overridden via input files. Wiki pages on this subject: https://github.com/nasa/gunns/wiki/Intro_Course_2_5 https://github.com/nasa/gunns/wiki/Trick_Sim_Products#overriding-default-data-optional
2. You don't use the input file to get outputs from the models during run. But you can use the input file to schedule inputs to the sim that will 'fire' at a pre-determined time during run (open the valve at 10 seconds, etc.) You do this with the _trick.addread(time, "expression") statement in the input file. For example: _trick.addread(10.0, "myTestSimObject.myFluidNetwork.propValve.mPosition = 1.0"). To get data out of the models, like outputs of a sensor, you can either look at it in Trick View, write a Trick Variable Server client to connect to your external app, or log data using Trick Data Record. The TVS client can also be used to set variables in addition to read them.
3. Yes there are lots of malfunctions in the GUNNS models. Most are documented in the link help pages. All malf control variables have the name convention mMalf... You can use the search pane in Trick View to search for all malfs in the model by searching for mMalf. All are activated with a flag (True is active, False inactive), and some have one or more extra parameters that quantify the malf (like leak rate, blockage value, etc.). To activate a malfunction, set its activation flag and extra parameters whenever you like. Malfunction effects propagate in a realistic physical way. For example if you leak the propellant ullage, the propellant pressure and flow rate will drop accordingly.

[rmfranz13]

Not a question, just figured you deserve an update. GUNNS is very well made and has so far met or exceeded all our expectations. Thanks for all the work you put into it.

[jasonlharvey]

Thanks, I'm glad it is useful to you! Just curious, are you in a NASA CLPS contract? Feel free to contact me at my NASA email if you have more questions -- see the Contact Info wiki page. I'm going to close this issue now.

[rmfranz13]

Thanks, will do. And yes, NOVA-C is being developed on a CLPS contract by Intuitive Machines. GUNNS at least on the surface appears to be something of a jackpot. It checks all the boxes we needed and more: It was written for Trick, it gives us the prop system modeling we were seeking, seemingly to the fidelity we need, it potentially gives us electric and thermal circuit modelling we may need in the future, and it's certainly easier to dive into than our production sim... I'll say that much... and it's all for free. Win, win, win, win.