2024-02-14 Big Grid

[sbenthall]

seeds = 40

AMMPS config parameters:

--mm_lucas_factor [0.0, 0.01, 0.1, 1.0] --dividend_std [0.0055, 0.00825, 0.011] [This should be synced across SHARKFin and AMMPS!]

SHARKFin parameters:

--dphm [1, 20.1, 403.4, 1096.6, 2981.0]

--attention [0.001, 0.01, 0.1, 0.5, 1.0] --zeta [0.0, 0.25, 0.5, 0.75, 1.0]

--dividend_growth_rate 1.0002 --dividend_std [0.0055, .00825, 0.011] [This should be synced across SHARKFin and AMMPS!]

--pop_CRRA 5 --pop_DiscFac 0.974

size: 60000

This is big! But if we can pull the data while it's still processing, and the grid is being sampled uniformally, then we can run this and pull data while we write.

Please don't execute this yet; we still need a passing smoke test.

[wjt5121]

@sbenthall I'm staging this now and will be ready to kick it off when you give the green light. And yes all simulations in a the first seed will be completed before moving on the next seed before onto the thirds etc..

[sbenthall]

@wjt5121 GREEN LIGHT! HIT IT!

[wjt5121]

And... we're off!!!

JEBO_jebos40seed_parametergrid.csv.zip

[sbenthall]

Good morning @wjt5121

I've been able to access the data, and there is some we can start working with. Thank you.

There is one problem. The script is properly rotating through all of the design parameters except for one, the --dphm parameter. ~1500 runs have completed at this time, but they all have --dphm 1.0; where I would expect 1 seed to have been executed for each grid point, 5 seeds have been executed on the first 4 dimensions of the grid.

Do you see the problem?

Is there a way to change the execution order to rotate through --dphm? This is an important design variable for our study.

[sbenthall]

Indeed, if we from now on used only dphm values of 403.4, 1096.6, 2981.0, that would make the remaining runs today be more efficient.

[wjt5121]

Good morning @sbenthall , So the dphm parameter does appear to be properly distributed across the grid, and those simulations are being executed however they are reported SHARKfin error when the simulation is started.

Traceback (most recent call last): File "/usr/simulation/SHARKFin/simulate/run_any_simulation.py", line 304, in <module> dphm = int(args.dphm) ValueError: invalid literal for int() with base 10: '1096.6'

[ammpssharkfin@startfish-hpc-pg0-1 sharkfin]$ cat shark_jebos40seed1601_err.log Traceback (most recent call last): File "/usr/simulation/SHARKFin/simulate/run_any_simulation.py", line 304, in <module> dphm = int(args.dphm) ValueError: invalid literal for int() with base 10: '2981.0'

[wjt5121]

Have we ever used a --dphm value containing a decimal? From Chat-GPT

The error message you've encountered, ValueError: invalid literal for int() with base 10: '2981.0', arises from a common issue in programming where there's an attempt to convert a string representing a floating-point number ('2981.0') into an integer directly without first converting it to a float. This error is seen in Python when using functions like int() that are designed to convert string or numeric values to integers. The int() function expects the string to represent a whole number, and when it encounters a decimal point, it doesn't know how to handle it, leading to a ValueError.

Python's int() function is strict in terms of the input it accepts. It can convert strings that look exactly like integers (e.g., '123') directly into integer values (e.g., 123), but it cannot handle strings that represent floating-point numbers directly. On the other hand, the float() function is more flexible, capable of converting strings that represent floating-point numbers (e.g., '123.45') into float values (e.g., 123.45). Once you have a floating-point number, you can then convert it to an integer using the int() function, which will remove the decimal part without rounding (truncating towards zero).

Convert to Float First: Convert the string to a float first, and then convert the float to an integer. This is a two-step process but is necessary to handle the decimal part correctly.

s = '2981.0' # The original string f = float(s) # Convert to float first i = int(f) # Then convert to int

[sbenthall]

oh dang. That is my bad then. I didn't realize those needed to be integers.

Is there any way to change or add to the grid the following DPHM values (just the old ones rounded):

20, 403, 1097, 2981

[sbenthall]

@wjt5121 Yes, your (ChatGPT-assisted) analysis is spot on. We could proceed without a change to the software if we adjust the grid parameters.

[wjt5121]

@sbenthall Update the values in the grid is no problem, however if you perfer the decimals for the study I could pause the run and restart with 'patched' code. Whichever you prefer is good with me.

[wjt5121]

@sbenthall sorry I didn't see your last message before I sent mine. I'll update the grid and and prioritize the missing simulations in the runs.

[sbenthall]

@wjt5121 Thinking to over -- I think it would be better to just stop the current run and start with a new grid. The current one is too big for the time we have today.

We can still use the data we have so far from this, but we need to focus on some other regions of the space for now.

I'll make a new issue with a corrected grid.