Better shutdown sequence for ammps and sharkfin

[mesalas]

I think our current shutdown sequence is causing some problems and Id like to propose a more clean solution. My suggested sequence is as follows:

Say we want to simulate T days. Currently we send a shutdown signal to ammps after T days have been simulated. I think in some cases this can cause ammps to finish its simulation because it finishes to process its data before receiving the signal. Another possible case is that shakfin sends the shutdown signal but close the connection (and maybe the queue?) before ammps it able to grab it.

Instead I suggest we send the shutdown signal along with buy and sell targets for day T. Instead of shutting down upon receiving the signal it will run the day, and only after sending the result of day T it will initiate the shutdown sequence. In stead of thinking of the shutdown signal as an "off switch" that halts the simulation we can think of it an a flag telling ammps that we are on the final day of the sim and to halt once the result of that day has been sent.

[mesalas]

@sbenthall I have taken a quick stab at implementing the sequence described above and It seems to work with ammps.

Im not super happy about the solution as it moves the logic for closing the connection into the trade function, also it will not work if the runs_per_dayis not 60, but I think the way we shut down is much more clean. Id like to do some tests with @gms158 to see if it removes some of the issues we been having when we shut down.

[sbenthall]

Next step: @gms158 to test this branch/container combo to see if it actually solves the problem.

[gms158]

@sbenthall , ok so rebuild master, and then what DOE to use to test ? the previous run, but with just 3 replicates ?

[sbenthall]

@gms158 No, not quite....

Check in with @mesalas about this. But the key is to use the i168 branch of SHARKFin and the sharkfin_i168 branch of amm.engine -- I'm not sure how to get the binary for that into the container. But a special container needs to be built to test this, since the changes have not been merged to master yet. (We are still checking to see if this solves anything).

Let's try testing with the new grid for Whiteshark, which is:

8 quarters, and:

• DPHM : [1000, 5000, 10000, 15000]
• dividend_growth_rate : [1.00, 1.0005, 1.0015]
• attention : [0.05, 0.35, 0.70, 0.95]
• p1 : [0.01, 0.1, 0.5, 0.99]
• p2: [0.01, 0.1, 0.5, 0.99]

But since that is already a big grid, just use 1 sample per point.

[gms158]

@mesalas @sbenthall : the above sharkfin_i168 link results in a 404 error for me. Can you direct me to another link with the ammps binaries ? , or can you create or updated branch in your ammps_sharkfin_container project with the updated binaries

[sbenthall]

@mesalas to make a new branch of the container repo with the sharkfin_i168

[mesalas]

@gms158 Theres a branch in the ammps_sharkfin_container repository with these changes. You should be able to test this by pulling the branch and building the container.

[gms158]

ok, started run on azure, Bill is running the same run in parallel, if results are the same, we can transition and run using Bill's slurm approach since it is faster and cheaper

[sbenthall]

We ran this experiment and it did not solve the Error 3 issue. Something else is going on, and we won't merge these changes.