Fix/speed trace from slts in ssts

[calbaker]

To verify that the loco_con and other objects are the same between the two simulations, you can:

1. run pip install deepdiff
2. run speed_limit_train_sim_demo.py interactively
3. do something like loco_con_slts = loco_con
4. run set_speed_train_sim_demo.py interactively in the same session
5. run

from deepdiff import DeepDiff
import json
DeepDiff(
    json.loads(loco_con.to_json()),
    json.loads(loco_con_slts.to_json()),
)

and this will show that they're equal or specifically what's not equal if they're not. I have not checked everything exhaustively yet but am working on it.

You can now run debugging plots to produce:

• double check that the above plot now shows line on line

This shows that the train resistance is different between the ssts and slts. I'm working on tracking this down.

[calbaker]

I believe I found the culprit:

Generated in e02ccf0

[calbaker]

[calbaker]

altrios/rust/altrios-core/src/train/speed_limit_train_sim.rs

Line 563 in 5ca2383

self.state.pwr_whl_out = self.state.pwr_whl_out.max(-pwr_neg_max).min(pwr_pos_max);

is making me suspicious

[calbaker]

@SWRIganderson , seeing this line that Geordie wrote was my inspiration for the change. Also, I think we could prove that the two simulations produce identical results by making a variant for the traction-dependent component of the aux load so that this can be turned off during regen and/or dynamic braking, which should remove the only difference I know of.

[calbaker]

@SWRIganderson , this PR sure could use some love

[SWRIganderson]

@calbaker I added a bunch of comments about set_speed_train_sim in commit 8c61cbc. I'll get the speed_limit)_train_sim knocked out soon. My biggest complaint is "res_net". We need change some nomenclature. res = reversible energy storage. Not resistance in my book. This is a minor nuisance in my book though.

[SWRIganderson]

@calbaker Check out commit 783039e. I have some comments in the speed limit train sim file. I am thinking that a key difference is that we pass speedtrace.dt in for a couple of arguments instead of self.state.dt. I am wondering if our states that we are using for energy calcs are off by one time step. Can we update the code to consistently use self.state.dt where ever possible. I am only half way through commenting the speed limit train sim file, but I feel like this could be something.

[calbaker]

@SWRIganderson, as we have it now, aux load is determined entirely at the locomotive level and is solely dependent on a constant and tractive-power coefficient. As such, there's no need to pass this in. This obviously should be more sophisticated to account for other factors that impact aux load. I have lots of thoughts, but they all need vetting from another engineer, e.g. you!

[SWRIganderson]

I agree that we should have something more sophisticated. I think this needs to go down to the component/subsystem level so that we can capture differences between engine, battery, or traction motor aux loads. Not sure how we will validate against data though.

[calbaker]

@SWRIganderson , we've done some of this type of stuff in FASTSim. I am 98% sure I have multiple issues saying that we need better aux modeling so we'll get back to it when it becomes important.

[calbaker]

@SWRIganderson because the SpeedLimitTrainSim has a TimedLinkPath that contains a coarse speed trace, meaning that the train has to hit specified locations at specified times but that the exact speed is up to the train.

[calbaker]

@SWRIganderson , hopefully https://github.com/NREL/altrios/pull/63/files#r1755701856 provides an explanation of why we would not want to do this.

[calbaker]

@SWRIganderson Probably not because it's a cheap calculation, and since I have aspirations of eventually incorporating our rust solver package to optionally have variable time step solvers, I would not want to had code this.