Bug in Trick's MCG (Trick v.19.7.1)

[jagalle2]

The monte_input.py files generated by mc_master.cc are putting the line to execute the desired run's input deck too early in the script, resulting in the run executing before dispersed variable values have been set. The monte carlo will run, but will use identical values for all variables in each run, instead of the dispersed set.

Line 177 needs to be relocated to line 188 as shown above so that the run's input.py file is executed after setting the variable values.

Here is an example of the MCG generated input deck with the exec() function too early. It is on line 4, but the variable values to be used by this file aren't set until after line 7. After moving line 177 to 188, as in the picture above, I have verified that the exec() function in the generated file is now at line 78 - after the variable values are set.

@ddj116

[ddj116]

@jagalle2 can you help me understand your use case better? If RUN_MC1A/input.py is the input file passed to ./S_main.. when MCG is turned on, what is monte_prepend.py and how is it ending up on line 7 as shown above? Are you using trick.MonteCarloPythonFileExec in this configuration?

As far as I can tell, what you've described above is exactly what MCG is supposed to do - execute the input file first (which presumably sets all variables to their values as in any nominal run), then MCG tacks on dispersions for variables at the end, overwriting their initial nominal values from the input file. For example, in the test sim which ships with trick under test/SIM_mc_generation, running ./S_main_... RUN_nominal/input_a.py will generate MONTE_RUN_nominal/RUN_000/monte_input_a.py with the following content:

monte_carlo.mc_master.active = True
monte_carlo.mc_master.generate_dispersions = False

exec(open('RUN_nominal/input_a.py').read())
monte_carlo.mc_master.monte_run_number = 0

test.x_uniform = 15.92844616516683
test.x_normal = 9.954870507417668
test.x_normal_trunc[0] = 9.954870507417668
test.x_normal_trunc[1] = 9.954870507417668
test.x_normal_trunc[2] = 9.954870507417668
test.x_normal_trunc[3] = 9.954870507417668
test.x_normal_trunc[4] = 3.772280419911035
test.x_normal_length = trick.attach_units("ft", 9.954870507417668)
test.x_integer = 1
test.x_string = "ABC"
test.x_line_command = test.x_integer * test.x_uniform
test.standalone_function( test.x_normal)
exec(open('Modified_data/sample.py').read())
test.x_boolean = True
test.x_file_lookup[0] = 2
test.x_file_lookup[1] = 1
test.x_file_lookup[2] = 0
test.x_fixed_value_int = 7
test.x_fixed_value_double = 7
test.x_fixed_value_string = "7"
test.x_semi_fixed_value =  2

Here the nominal input file RUN_nominal/input_a.py is sourced, then the dispersion-assigned values overwrite those nominal values afterwards.

[jagalle2]

@ddj116 We were previously using the mc_*.hh files that are in iss/cml/models/utilities/monte_carlo/include as we were on Trick17. When running a MC set such as monte.py --mode=local RUN_MC1A/input.py --mc_num_runs=10, it would generate a MONTE_RUN_MC1A/RUN_0000*/monte_input.py file which executed the RUN_MC1A/input.py file after setting the dispersed values. Using the Trick provided copies of these files produces different results where that auto generated file now executes RUN_MC1A/input.py before said values are set.

These values cannot be overwritten after executing exec(open('RUN_nominal/input_a.py').read()) as the next line of code monte_carlo.mc_master.monte_run_number = 0 won't execute until after that sim run's completion. We have verified that a 10 run MC set is the identical run over and over, unless the requested change is made - which then results in 10 slightly different runs as expected.

So in a nutshell, the input deck for the run is getting executed, using the default variable values. It runs to completion and only once it is finished are the variables values being changed to the dispersed value. Then the process repeats.

Don't think I mentioned explicitly, we are using the monte.py script in iss/bin

[hchen99]

@ddj116 Wondering if y'all looking into updating monte.py script in iss/bin or something else?

[ddj116]

@jagalle2 and I have talked offline about this - it looks like the version of CML monte-carlo (a copy of MCG from a few years ago) that they have been using was altered from it's original design, but he wasn't aware of the change so it looked like Trick made a change to MCG when in fact we never did.

I suspect this issue can be closed but I'll let @jagalle2 comment on where he's at in the investigation.

[jagalle2]

@ddj116 I concur, and think we can close this. Haven't had a chance to dive into it yet, as I've been pulled to higher priority tasks, but from our conversation it looks like the change was made on our end at some point. I'll probably circle back to you offline if I need a little help when the time comes.

[sharmeye]

closing. bock.