You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The harness has many automatic replacements that aren't derived from rgt_test_input.ini. For example - working_dir, scripts_dir, results_dir.
I think we need to document all the possibilities, because I am even surprised sometimes by new replacements.
The text was updated successfully, but these errors were encountered:
In addition, we should also document all automatically-created test-specific environment variables. We have documented that the variables from machine.ini get added to the environment -- good. But we also have several variables that seem to be created by the harness automatically like
And in our current Slurm template that we provide, we ultimately duplicate these fields by using the replacements of __working_dir__, __results_dir__, etc.
I think we might want to consider using these fields in the template and even in check scripts.
Rationale:
I'm thinking of a case where the user runs something like "set_harness_environment.py" from within a test's Run_Archive directory, and "set_harness_environment.py" sets the RGT_TEST_* variables. Now, the user could potentially run the check/report scripts by hand (or run the check_executable_driver.py script more easily).
One pitfall that comes to mind:
Paths wouldn't be hard-coded within the job script
The harness has many automatic replacements that aren't derived from
rgt_test_input.ini
. For example -working_dir
,scripts_dir
,results_dir
.I think we need to document all the possibilities, because I am even surprised sometimes by new replacements.
The text was updated successfully, but these errors were encountered: