mirror of
https://github.com/nasa/trick.git
synced 2024-12-27 08:32:30 +00:00
19025d77ad
Reorganized. Created a new top level include directory that will hold all of Trick's header files. Moved all of the Trick headers to this directory. Created a libexec directory that holds all of the executables that users don't need to execute directly. Changed all of the executables remaining in bin to start with "trick-". In the sim_services directories changed all source files to find the Trick headers in their new location. Since all of the include files are gone in sim_services, removed the src directories as well, moving all of the source files up a level. Moved the makefiles, docs, man, and other architecture independent files into a top level share directory. Renamed lib_${TRICK_HOST_CPU} to lib64 or lib depending on the platform we're currently on.
refs #63
92 lines
4.9 KiB
Plaintext
92 lines
4.9 KiB
Plaintext
/**
|
|
* @anchor MonteCarloPage
|
|
* @page LEVEL2 Monte Carlo and Optimization
|
|
*
|
|
* Monte Carlo is the process of iteratively calling a simulation over a set of predetermined or auto-generated inputs.
|
|
* Trick has designed its Monte Carlo capability to run distributed.
|
|
*
|
|
* @section LEVEL3 Structure
|
|
* In particular, Monte Carlo is designed after a "master/slave" model. The master is in charge of creating slaves and
|
|
* tasking them to work. There may be any number of slaves distributed over a network. Master and slave communicate through
|
|
* sockets. Theoretically, a master and slave need not have the same file system. Each slave is responsible for requesting
|
|
* work, accomplishing work and reporting results. The work at hand is running a single simulation iteratively over an input
|
|
* space.
|
|
*
|
|
* @subsection LEVEL4 The Master
|
|
* The master is the command center of a Monte Carlo simulation. The master tasks slaves to run the simulation with a given
|
|
* set of inputs. The master will task slaves to run in parallel. The master is responsible for keeping the slaves as busy as
|
|
* possible. To keep things running smoothly, the master is designed to reassign work when a slave is either dead or running
|
|
* too slowly. the master is only in charge of tasking work. The master does not run the simulation itself. The master will
|
|
* continue issuing work to the slaves until it is satisfied all simulation runs are complete.
|
|
*
|
|
* The master's life cycle consists of the following:
|
|
*
|
|
* - Initialize
|
|
* - While there are unresolved runs:
|
|
* - Spawn any uninitialized slaves.
|
|
* - Dispatch runs to ready slaves.
|
|
* - Resolve run based on slave's exit status.
|
|
* - Receive results from finished slave's child.
|
|
* - Check for timeouts.
|
|
* - Shutdown the slaves and terminate.
|
|
*
|
|
* @see Trick::MonteCarlo
|
|
*
|
|
* @anchor MonteCarloSlaves
|
|
* @subsection LEVEL4 Slaves
|
|
*
|
|
* A slave consists of a parent and fork()ed children. A slave parent spawns a child using the fork() system call. A
|
|
* slave child runs the simulation in its own address space. Only one child exists at a time in a slave. Per slave,
|
|
* simulation execution is sequential.
|
|
*
|
|
* A slave is responsible for requesting work from the master, running a Trick simulation with inputs given by the master,
|
|
* dumping recorded data to disk and informing the master when it is finished running its task.
|
|
*
|
|
* The slave's life cycle consists of the following:
|
|
*
|
|
* - Initialize
|
|
* - Connect to and inform the master of the port over which the slave is listening for dispatches.
|
|
* - Until the connection to the master is lost or the master commands a shutdown:
|
|
* - Wait for a new dispatch.
|
|
* - Process the dispatch.
|
|
* - Slave fork()s child.
|
|
* - Child runs simulation with varied input.
|
|
* - Write the run number processed to the master at child shutdown.
|
|
* - Write the exit status to the master.
|
|
* - Run the shutdown jobs and terminate.
|
|
*
|
|
* @see Trick::MonteSlave
|
|
*
|
|
* @section LEVEL3 Simulation Inputs
|
|
*
|
|
* The goal of Monte Carlo is to run the simulation over a set of inputs. The inputs that the master passes to the slaves
|
|
* are either generated by a statistical algorithm or they are hard-coded by the user in a data file. Inputs may also be
|
|
* generated exclusively by user calculations.
|
|
*
|
|
* @section LEVEL3 Monte Carlo Output
|
|
*
|
|
* For each simulation run within a Monte Carlo suite of runs, a directory called "MONTE_<name>" is created. Slave output
|
|
* is directed to this "MONTE_" directory. Trick recorded data is written in a set of "RUN_" directories within the parent
|
|
* "MONTE_" directory. Along with recorded data, stdout, stderr, and send_hs files are written. A file that contains the
|
|
* summary of all runs is written to the "MONTE_" directory.
|
|
*
|
|
* @section LEVEL3 Data Processing
|
|
*
|
|
* The trick_dp is desinged to understand "MONTE_" directories. When choosing to plot a "MONTE_" directory, trick_dp
|
|
* will overlay all curves from each "RUN_" directory within the parent "MONTE_" directory. The plot widget has built
|
|
* in features that allow the developer to distinguish what curve goes with what simulation run.
|
|
*
|
|
* @section LEVEL3 Optimization
|
|
*
|
|
* Optimization is made possible by creating a framework whereby the developer can change simulation inputs based on
|
|
* simulation results. Trick offers a set of job classes that allow the developer to enter the Monte Carlo loop and
|
|
* thereby enter the decision making on-the-fly. No canned optimization is available.
|
|
*
|
|
* This special set of job classes work in concert together in master and slaves. Trick schedules jobs within the master
|
|
* at critical points so that they may create inputs to send to the slave as well as receive results from the slave.
|
|
* Slave jobs are scheduled to receive simulation inputs from the master as well as send simulation results back to the
|
|
* master.
|
|
*
|
|
* The jobs are specified in the S_define. The jobs are created by the developer.
|
|
*/
|