VesselTransorbital tug / Hauler

jedidia

shoemaker without legs
Are you trying to simulate the actual fission reaction? ?

Urwumpe

Not funny anymore
Donator
Are you trying to simulate the actual fission reaction? ?

On a coarse level - so, not fission reaction - but rather something on the scale of 1E20 fission reactions (per timestep) as one "matrix" operation... This is already the 4th iteration of simplication, from a model for engineering calculations on a PC....

Maybe still too complex. But I have no tables for reactor performance available to implement yet. Also, since it is using Uranium Carbide as fuel, the effect of Carbon as moderator is important.

Since we can ramp the power up and down, I need something that can model Xenon poisoning, also I need to consider the H2 flow in the core for a reactor performance function. The burn down of the fuel is also important, since it affects the maximum temperature of the H2 at the end of the engine lifetime.

I have no idea, if I could use one of those to produce precalculated tables for further simplifying the model.

Last edited:

jedidia

shoemaker without legs
Well, I just hope I'll be able to fly the thing in the end. I'm not a nuclear engineer... ?

Urwumpe

Not funny anymore
Donator
Well, I just hope I'll be able to fly the thing in the end. I'm not a nuclear engineer... ?

Same here - I once was a CFD simulation guy, including car coolant loop simulations... thats about the closest thing I can offer there. ?

I'll look for a simpler model, sadly there are no NTR simulations off the shelf. Maybe I just didn't ask loud enough.

Urwumpe

Not funny anymore
Donator
Maybe this is an option?

Sadly it only cares about the NTR performance, not Brayton Cycle power generation. So the low power reactor behaviour is missing.

This here calculates a similar engine:

Reading what they have done for their calculations, they used the same math I wanted to implement in real-time. So my idea had not been too stupid.

OK, it was.

But yeah, we need something simpler.

Would 12 tons of thrust in pure NTR mode be enough for our case? With oxygen afterburner, this would go up to four times the thrust (~45 tons @ MR=4) Which should be more than enough for hauling the spacecraft plus 10 tons of payload outta Earth Orbit.

Last edited:

Urwumpe

Not funny anymore
Donator
So, I am now throwing all of the neutronics overboard and simply assume that some near-magical engine controller makes sure, that the reactor always produces the thermal power we need. I also drop decay heat for now, I can do it in the next iteration. Now it is all about that thrust. Maximum thrust should get limited by the hydrogen coolant massflow.

For the electrical power generation, I think about differing from the older LANTR design and use Helium-Xenon (HeXe?) as coolant, like NASA papers from 2014 suggested for fixing some stability problems in the reactor (Bad heat gradients). This would also be physically separated from the NTR mode. Should also improve the effectivity a lot. There is also no need to cool the other hardware in Brayton mode, since the thermal power of the nuclear reactor is reduced to about 1/1000th of the usual power, 530 kW, which is enough to provide about 80 kW of electricity at fairly poor efficiency (as feared by NASA). That is a luxurious amount of electricity for a manned spacecraft - its 5 times more than what the Space Shuttle used.

Instead of using just one loop as in the original LANTR schematic, I think about using three separate Brayton loops, adding a layer of redundancy there. We would then have three generators, that could power three main power buses.

For the NTR side, I think I will stick to using two RL-10 derived turbopumps for the hydrogen in NTR mode, because I already have data for that configuration.

N_Molson

Donator
For the NTR side, I think I will stick to using two RL-10 derived turbopumps for the hydrogen in NTR mode, because I already have data for that configuration.

Makes sense, that's pretty much the top of the basket when it comes to rocket upper stage engine parts

jedidia

shoemaker without legs
Maximum thrust should get limited by the hydrogen coolant massflow.
That is until you inject the LOX, I assume...

the thermal power of the nuclear reactor is reduced to about 1/1000th of the usual power,
How hot does it run in this mode? If it's running too cold, we might actually get into trouble with the radiator area designed for hotter operation... Oh well, that's a design detail at this stage. All in all, this sounds a lot more manageable than herding neutrons!

Urwumpe

Not funny anymore
Donator
How hot does it run in this mode? If it's running too cold, we might actually get into trouble with the radiator area designed for hotter operation... Oh well, that's a design detail at this stage. All in all, this sounds a lot more manageable than herding neutrons!

Well, a reference design from NASA with 50 kWe uses three bimodal NTR engines, producing HeXe gas at 1300 K. The coolant enters the (single) main radiator there with 65 m² at 929 K, and goes into the compressor at 382 K and returns to the reactor at 606K.

At full thrust mode, we might need to cool the HeXe down a lot before letting it pass the turbines. Since there is 20 times more hydrogen mass flow going into the reactor core then, then HeXe circulating through the reactor, we could use the cool hydrogen there as heat sink. A quick estimation of the heat exchange using newtons law results in the hydrogen warming from 367 to 380 K, while the HeXe cools down from 2700K to 1668K.

No idea, how thick the pipes in such a heat exchanger have to be, but the first estimates to get the needed 1000W/K in this scenario suggests that even a short length of heat exchanger should be enough to do this, which means it could be a part of the reactor vessel, without any moving parts involved.

EDIT: I should really produce a new engine schematic for this one. Its so many changes to the original LANTR schematic now.

Last edited:

jedidia

shoemaker without legs
I've been chipping away at that VC abstraction, and it went pretty well so far. I can define a panel with an arbitrary position and rotation, and I can place switches on it with 2-dimensional coordinates that then load their meshes and position and rotate them properly, panel areas and animations included. Haven't added texture surfaces and MFDs yet, but shouldn't be too hard once I get the structure nailed down.

Since I've stumbled over animations, and since I'd like to define the button templates in config files rather than hardcode them in, I've taken a little detour to pull in the animation framework from IMS2. That's going to need a bit of work though, it is rather too closely intertwined with the rest of the code base. Should still be worth it, since they already come config- and scenario ready and can handle proper state propagation by themselves. Also supports more advanced stuff like looping and tracking animations as a bonus, though I guess we're at best going to use that tracking animation for the comm dish...

Urwumpe

Not funny anymore
Donator
I still slowly work on the reactor model, or at least, as fast as my family permits (OK, we watched three episodes of Daredevil today after the children had been asleep.) Current goal for the first Pull Request is getting towards having a thruster function ready (NTR mode, LANTR mode) and enough indicators implemented to go on with the Brayton Cycle simulation. I think most of the behaviour can be approximated well by linear relationships (e.g. how mass flow through the reactor ramps up when starting the turbo pump), the challenge is only calculating how things scale and how fast the reactor shall react (e.g. Where is the limit for the reactivity during NTR start-up? Examples from science use 340 pcm. )

Could the framework also handle TVC animations? I am not sure, if we want to do this (TVC for a NTR is a special case of engineering it seems), but it would be one further option. Initially, I thought about having a central plug nozzle valve in the throat of the rocket engines, but with the new HeXe-cycle separate from the hydrogen flow, this can be omitted. The only kind of visual effect for the engine itself, that is left, is letting the different materials of the propulsion system glow as it heats up, some parts would be at 1700K during regular operation (And at 2800K during NTR mode). There would not even be any moving part inside the reactor beyond the (sadly invisible) control drums inside the reflector. Unless I missed something, all valves can be placed in front of the gamma shield, closer to the turbopumps and the turbo generators.

Also, getting the reactor to minimum power output in Brayton mode ("idle") should be longer process - while the reactor is rather small (about 1.5m long and 70cm diameter), going from almost zero to 1700K is a lot of thermal expansion, I suspect something along one hour is maximum there, playing with the numbers gets me some guestimate of at least 10 minutes.

Getting from 1700K to 2800K on the other hand happens in a few seconds and should be mostly limited by the speed up of the turbo pump for preventing overheating.

jedidia

shoemaker without legs
(OK, we watched three episodes of Daredevil today after the children had been asleep.)
Crashing together dead tired in front of the TV is indeed an important aspect of any marriage!

Could the framework also handle TVC animations?
After thinking about it really hard and finding nothing on google, I have concluded that TVC probably means Thrust Vector... Control? Something like that?
Technically, yes. Animations can be modified on the fly by events, but so far I have no convenient abstraction for an "unscoped" animation that doesn't have a defined target state, if you understand what I mean. Could be added, just never had any use for it so far.

Urwumpe

Not funny anymore
Donator
Yes, Thrust Vector Control - having a small amount of control there, would allow more range for the superstructure CoG.

Urwumpe

Not funny anymore
Donator
I had some trouble compiling for testing, maybe you can take a look there - the std namespace stuff was not found because the OParse headers had some unknown dependency on the order, I think.

I now have a small test MFD for displaying the key data of the power plant. Also I think calling the main engine "POWERplant" sounds more impressive and adequate. ?

I will add some buttons to the MFD along the work to allow switching the engine modes, but that is just meant for testing - later this should get included into a proper UI.

N_Molson

Donator
There would not even be any moving part inside the reactor beyond the (sadly invisible) control drums inside the reflector.

Oh, feel free to add a "cutaway mode", like they did in KSP for the crewed parts, looking at a working reactor would be quite cool

Urwumpe

Not funny anymore
Donator
Oh, feel free to add a "cutaway mode", like they did in KSP for the crewed parts, looking at a working reactor would be quite cool

It should be really anticlimatic. If you want to turn this into something cool, you have to add a geiger counter noise to the external camera view....

Yeah, we have a nuclear reactor with the thermal power of the decommissioned Phénix reactor about 35m away from the crew. What could possibly go wrong?

jedidia

shoemaker without legs
I had some trouble compiling for testing, maybe you can take a look there - the std namespace stuff was not found because the OParse headers had some unknown dependency on the order, I think.
Hmmm, possibly an artifact from pulling the Oparse project into the solution? I had not expected anyone to do that. In any case, Oparses own include folder seems to be missing in that project configuration (.\include). It's really weird though, because it is there when I open the project by itself.
Also, we don't seem to have quite the same windows SDK, at least VisualStudio wanted to migrate them to 10 when I opened the solution I cloned from your repo.

Urwumpe

Not funny anymore
Donator
No, I am also on 10.0 according to the project settings.

Its weird. Can we use the dependency handling of visual studio?

Some small progress again:

A first prototype MFD for the POWERPLANT. On top is the current operating mode and controller state, followed by the indications. I think I will change them in different operating modes to display only the important data and leave the rest to special displays. The weak neutron flux comes from a neutron source inside the reactor.

Below is the error log of the engine controller. In this case, it signals an reactor scram ("X") on the 87th day of the year and 12:46 GMT, caused by a crew command (pressing the SCR button).

I think I will keep a 1980s style sci-fi look there, maximal "Escape from New York".

Next work is turning the reactor on. In this case, the neutron flux and coolant temperature will be important, as well as coolant flow. After a short self-test of the controller, the reactor will first of all pressurize and circulate the coolant by battery power, before starting to increase criticality. Once the turbine starts spinning up by increasing HeXe pressure, the reactor will slowly switch from consuming power for circulating coolant to producing power for itself.

Arvil

Well-known member
Just curious. I don't know much about this style reactor, obviously nothing like the pressurized water plants on my Enterprise. What is the heat sink for the fission products after shutdown? Of course that can be minimized if it was run near idle for a substantial time before shutdown. We ran the turbogenerators until residual product output decreased enough, then dumped steam to the main condenser. Would the coolant pumps with radiators to space be enough heat sink? Are you planning on criticality be used to heat the reactor or just use the coolant pumps. We used the coolant pumps and fluid friction to heat up the plant before pulling rods.
I think it'll be interesting to play with this one.
Never mind the shutdown part, I just realized your #106 where you said you'll ignore decay heat for now.

Last edited:

jedidia

shoemaker without legs
Its weird. Can we use the dependency handling of visual studio?
We can, if you quickly explain how that works and how to set it up... I thought what I was doing was the dependency handling of visual studio.
I'm not very fond of multi-module projects if the libraries are not really part of the project, i.e. I treat them as 3rd-party dependencies, because that's the level of separation I wanted them to have. In the case of Oparse that's a bit iffy though, since most of the code is contained in the headers anyways because they're doing a lot of generics, which apparently in C++ you have to do completely in the headers.

Replies
18
Views
757
Replies
31
Views
1K
Replies
137
Views
4K
Replies
2
Views
253
Replies
61
Views
3K