mirror of
https://github.com/nasa/trick.git
synced 2024-12-19 05:07:54 +00:00
9099792947
* Provide MonteCarloGenerate capability
Intermediate commit, this squash represents all of Isaac Reaves' work
during his Fall 2022 Pathways internship tour
[skip ci]
* TrickOps: Add phase, [min-max] range, and overhaul YAML verification
* Add new "phase:" mechanism to TrickOps Runs and Builds to support
project-specific constraints on build and run ordering
- phase defaults to zero if not specified and must be between -1000
and 1000 if given.
- jobs can now optionally be requested by their phase or phase range
- See trickops/README.md for details
* Add [min-max] notation capability to run: entries and compare: entries
- [min-max] ranges provide definition of a set of runs using a common
numbering scheme in the YAML file, greatly reducing YAML file size
for monte-carlo and other zero-padded run numbering use cases
- See trickops/README.md for details
* YAML parsing changes
- Overhaul the logic which verifies YAML files for the expected
TrickOps format. This is now done in TrickWorkflowYamlVerifier and
provides much more robust error checking than previous approach
- .yaml_requirements.yml now provides the required types, ranges, and
default values as applicable to expected entries in YAML files
- valgrind: is now an sub-option to run: entries, not its own section
Users should now list their runs normallly and define their flags in
in that run's valgrind: subsection
- parallel_safety is now a per-sim parameter and not global. Users
should move their global config to the sim layer
- self.config_errors is now a list of errors. Users should now
check for empty list when using instead of True/False
* Robustify the get_koviz_report_jobs unit test to work whether koviz
exists on PATH or not
* Adjust trickops.py to use the new phase and range features
- Make it more configurable on the command-line via argparse
- Move SIM_mc_generation tests into test_sims.yml
[skip ci]
* Code review and cleanup from PR #1389
Documentation:
* Adjust documentation to fit suggested symlinked approach. Also
cleaned up duplicate images and old documentation.
* Moved the verification section out of markdown and into a PDF since it
heavily leverages formatting not available in markdown.
* Clarify a couple points on the Darwin Trick install guide
* Update wiki to clarify that data recording strings is not supported
MCG Code:
* Replace MonteCarloVariableRandomNormal::is_near_equal with new
Trick::dbl_is_near from trick team
MCG Testing:
* Reduce the set of SIM_mc_generation comparisons. After discussion
the trick team, we are choosing to remove all comparisons to
verif_data/ which contain random-generated numbers since
these tests cannot pass across all supported trick platforms.
* Fix the wrong rule on exlcuding -Werror for Darwin builds
of SIM_mc_generation
* Remove data recording of strings in SIM_mc_generation
Trickops:
* Replace build_command with build_args per discussion w/ Trick team
Since we only support arguments to trick-CP, replace the build_command
yaml entry with build_args
* Disable var server connection by default in SingleRun if TrickWorkflow.quiet
is True
* Guard against multiple Job starts
* Remove SimulationJob inheritance layer since old monte-carlo wasn't
and never will be supported by TrickOps
* Ignore IOError raise from variable_server that looks like "The remote
endpoint has closed the connection". This appears to occur when
SingleRun jobs attempt to connect to the var server for a sim that
terminates very early
[skip ci]
* Adjust phasing of old/new MCG initialize functions
* Clarify failure message in generate_dispersions if new/old MC are both
used.
* Adjust the phasing order of MCG intialize method to be before
legacy MC initialized. Without this, monte-carlo dry run completes with
success before the check in generate_dispersions() can run
* Add -Wno-stringop-truncation to S_override.mk for SIM_mc_generation
since gcc 8+ warns about SWIG generated content in top.cpp
* Introduce MonteCarloGenerationHelper python class
This new class provides an easy-to-use interface for MCG sim-module
users:
1. Run generation
2. Getting an sbatch array job suitable for SLURM
3. Getting a list of SingleRun() instances for generated runs, to be
executed locally if desired
---------
Co-authored-by: Dan Jordan <daniel.d.jordan@nasa.gov>
|
||
|---|---|---|
| .. | ||
| FAIL_config_error | ||
| FAIL_duplicate_variable | ||
| FAIL_illegal_config | ||
| FAIL_invalid_config | ||
| FAIL_invalid_data_file | ||
| FAIL_IO_error | ||
| FAIL_malformed_data_file | ||
| IO_FAIL | ||
| IO_RUN_ERROR1 | ||
| IO_RUN_ERROR2 | ||
| Log_data | ||
| MCGTrickOps | ||
| Modified_data | ||
| MONTE_IO_FAIL | ||
| MONTE_IO_RUN_ERROR1 | ||
| MONTE_IO_RUN_ERROR2 | ||
| RUN_ERROR_file_inconsistent_skip | ||
| RUN_ERROR_invalid_call | ||
| RUN_ERROR_invalid_name | ||
| RUN_ERROR_invalid_sequence | ||
| RUN_ERROR_invalid_sequencing | ||
| RUN_ERROR_out_of_domain_error | ||
| RUN_ERROR_random_value_truncation | ||
| RUN_file_sequential | ||
| RUN_file_skip | ||
| RUN_file_skip2 | ||
| RUN_generate_meta_data_early | ||
| RUN_nominal | ||
| RUN_random_normal__untruncate | ||
| RUN_random_normal_truncate_abs | ||
| RUN_random_normal_truncate_rel | ||
| RUN_random_normal_truncate_sd | ||
| RUN_random_normal_untruncated | ||
| RUN_random_uniform | ||
| RUN_remove_variable | ||
| RUN_WARN_config_error | ||
| RUN_WARN_invalid_name | ||
| RUN_WARN_overconstrained_config | ||
| verif_data | ||
| README | ||
| S_define | ||
| S_overrides.mk | ||
Verification simulation of monte_carlo. The following tests rely on setting the directories to be non-writable. Their purpose is to detect situations in which the monte-carlo model cannot generate certain files. These tests by their very nature are difficult to run within an automated scripted testing system. IO_FAIL IO_RUN_ERROR1 IO_RUN_ERROR2 The following cases are expecting either a warning or an error but the simulation does not terminate. Instead, ZERO is returned. The purpose of these cases is to emit the error or warning, not generate viable datasets. Do not evaluate any of these cases for good dispersions. There is no telling what state the data is in after the warning / error message is emitted. RUN_ERROR_file_inconsistent_skip RUN_ERROR_invalid_call RUN_ERROR_invalid_name RUN_ERROR_invalid_sequence RUN_ERROR_invalid_sequencing RUN_ERROR_IO_error RUN_ERROR_IO_error2 RUN_ERROR_out_of_domain_error RUN_ERROR_random_value_truncation RUN_WARN_config_error RUN_WARN_invalid_name RUN_WARN_overconstrained_config The following cases emit a fatal error and the simulation halts in its tracks: FAIL_config_error FAIL_duplicate_variable FAIL_illegal_config FAIL_invalid_config FAIL_invalid_data_file FAIL_IO_error FAIL_IO_error2 FAIL_malformed_data_file