<!DOCTYPE html>
<html class="writer-html5" lang="en" >
<head>
  <meta charset="utf-8" /><meta name="generator" content="Docutils 0.17.1: http://docutils.sourceforge.net/" />

  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Population grid code options &mdash; binary_c-python  documentation</title>
      <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
      <link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
  <!--[if lt IE 9]>
    <script src="_static/js/html5shiv.min.js"></script>
  <![endif]-->
  
        <script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script>
        <script src="_static/jquery.js"></script>
        <script src="_static/underscore.js"></script>
        <script src="_static/doctools.js"></script>
        <script crossorigin="anonymous" integrity="sha256-Ae2Vz/4ePdIu6ZyI/5ZGsYnb+m0JlOmKPjt6XZ9JJkA=" src="https://cdnjs.cloudflare.com/ajax/libs/require.js/2.3.4/require.min.js"></script>
    <script src="_static/js/theme.js"></script>
    <link rel="index" title="Index" href="genindex.html" />
    <link rel="search" title="Search" href="search.html" />
    <link rel="prev" title="Binary_c parameters" href="binary_c_parameters.html" /> 
</head>

<body class="wy-body-for-nav"> 
  <div class="wy-grid-for-nav">
    <nav data-toggle="wy-nav-shift" class="wy-nav-side">
      <div class="wy-side-scroll">
        <div class="wy-side-nav-search" >
            <a href="index.html" class="icon icon-home"> binary_c-python
          </a>
<div role="search">
  <form id="rtd-search-form" class="wy-form" action="search.html" method="get">
    <input type="text" name="q" placeholder="Search docs" />
    <input type="hidden" name="check_keywords" value="yes" />
    <input type="hidden" name="area" value="default" />
  </form>
</div>
        </div><div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="Navigation menu">
              <p class="caption" role="heading"><span class="caption-text">Contents:</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="readme_link.html">Python module for binary_c</a></li>
<li class="toctree-l1"><a class="reference internal" href="modules.html">Binarycpython code</a></li>
<li class="toctree-l1"><a class="reference internal" href="example_notebooks.html">Example notebooks</a></li>
<li class="toctree-l1"><a class="reference internal" href="binary_c_parameters.html">Binary_c parameters</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">Population grid code options</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#public-options">Public options</a></li>
<li class="toctree-l2"><a class="reference internal" href="#moe-di-stefano-sampler-options">Moe &amp; di Stefano sampler options</a></li>
<li class="toctree-l2"><a class="reference internal" href="#private-options">Private options</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference external" href="https://gitlab.eps.surrey.ac.uk/ri0005/binary_c-python">Visit the GitLab repo</a></li>
<li class="toctree-l1"><a class="reference external" href="https://gitlab.eps.surrey.ac.uk/ri0005/binary_c-python/-/issues/new">Submit an issue</a></li>
</ul>

        </div>
      </div>
    </nav>

    <section data-toggle="wy-nav-shift" class="wy-nav-content-wrap"><nav class="wy-nav-top" aria-label="Mobile navigation menu" >
          <i data-toggle="wy-nav-top" class="fa fa-bars"></i>
          <a href="index.html">binary_c-python</a>
      </nav>

      <div class="wy-nav-content">
        <div class="rst-content">
          <div role="navigation" aria-label="Page navigation">
  <ul class="wy-breadcrumbs">
      <li><a href="index.html" class="icon icon-home"></a> &raquo;</li>
      <li>Population grid code options</li>
      <li class="wy-breadcrumbs-aside">
            <a href="_sources/grid_options_descriptions.rst.txt" rel="nofollow"> View page source</a>
      </li>
  </ul>
  <hr/>
</div>
          <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
           <div itemprop="articleBody">
             
  
<style>
/* CSS overrides for sphinx_rtd_theme */

/* 24px margin */
.nbinput.nblast.container,
.nboutput.nblast.container {
    margin-bottom: 19px;  /* padding has already 5px */
}

/* ... except between code cells! */
.nblast.container + .nbinput.container {
    margin-top: -19px;
}

.admonition > p:before {
    margin-right: 4px;  /* make room for the exclamation icon */
}

/* Fix math alignment, see https://github.com/rtfd/sphinx_rtd_theme/pull/686 */
.math {
    text-align: unset;
}
</style>
<section id="population-grid-code-options">
<h1>Population grid code options<a class="headerlink" href="#population-grid-code-options" title="Permalink to this headline"></a></h1>
<p>The following chapter contains all grid code options, along with their descriptions
There are 28 options that are not described yet.</p>
<section id="public-options">
<h2>Public options<a class="headerlink" href="#public-options" title="Permalink to this headline"></a></h2>
<p>The following options are meant to be changed by the user.</p>
<div class="line-block">
<div class="line"><strong>C_auto_logging</strong>: Dictionary containing parameters to be logged by binary_c. The structure of this dictionary is as follows: the key is used as the headline which the user can then catch. The value at that key is a list of binary_c system parameters (like star[0].mass)</div>
</div>
<div class="line-block">
<div class="line"><strong>C_logging_code</strong>: Variable to store the exact code that is used for the custom_logging. In this way the user can do more complex logging, as well as putting these logging strings in files.</div>
</div>
<div class="line-block">
<div class="line"><strong>HPC_force_join</strong>: Integer, default 0. If 1, and the HPC variable (“slurm” or “condor”) is 3, skip checking our own job and force the join.</div>
</div>
<div class="line-block">
<div class="line"><strong>HPC_rebuild_joinlist</strong>: Integer, default 0. If 1, ignore the joinlist we would usually use and rebuild it automatically</div>
</div>
<div class="line-block">
<div class="line"><strong>Moe2017_options</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>cache_dir</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>combine_ensemble_with_thread_joining</strong>: Boolean flag on whether to combine everything and return it to the user or if false: write it to data_dir/ensemble_output_{population_id}_{thread_id}.json</div>
</div>
<div class="line-block">
<div class="line"><strong>command_line</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>condor</strong>: Integer flag used to control HTCondor (referred to as Condor here) jobs. Default is 0 which means no Condor. 1 means launch Condor jobs. Do not manually set this to 2 (run Condor jobs) or 3 (join Condor job data) unless you know what you are doing, this is usually done for you.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_ClusterID</strong>: Integer. Condor ClusterID variable, equivalent to Slurm’s jobid. Jobs are numbered &lt;ClusterID&gt;.&lt;Process&gt;</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_Process</strong>: Integer. Condor Process variable, equivalent to Slurm’s jobarrayindex. Jobs are numbered &lt;ClusterID&gt;.&lt;Process&gt;</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_bash</strong>: String. Points the location of the “bash” command, e.g. /bin/bash, that is used in Condor launch scripts. This is set automatically on the submit machine, so if it is different on the nodes, you should set it manually.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_batchname</strong>: String. Condor batchname option: this is what appears in condor_q. Defaults to “binary_c-condor”</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_date</strong>: String. Points the location of the “date” command, e.g. /usr/bin/date, that is used in Condor launch scripts. This is set automatically on the submit machine, so if it is different on the nodes, you should set it manually.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_dir</strong>: String. Working directory containing e.g. scripts, output, logs (e.g. should be NFS available to all jobs). This directory should not exist when you launch the Condor jobs.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_env</strong>: String. Points the location of the “env” command, e.g. /usr/bin/env or /bin/env, that is used in Condor launch scripts. This is set automatically on the submit machine, so if it is different on the nodes, you should set it manually.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_extra_settings</strong>: Dictionary. Place to put extra configuration for the CONDOR submit file. The key and value of the dict will become the key and value of the line in te slurm batch file. Will be put in after all the other settings (and before the command). Take care not to overwrite something without really meaning to do so.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_getenv</strong>: Boolean. If True, the default, condor takes the environment at submission and copies it to the jobs. You almost certainly want this to be True.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_initial_dir</strong>: String. Directory from which condor scripts are run. If set to the default, None, this is the directory from which your script is run.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_kill_sig</strong>: String. Signal Condor should use to stop a process. Note that grid.py expects this to be “SIGINT” which is the default.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_memory</strong>: Integer. In MB, the memory use (ImageSize) of the job.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_njobs</strong>: Integer. Number of jobs that Condor will run</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_postpone_join</strong>: Integer. Use to delay the joining of Condor grid data. If 1, data is not joined, e.g. if you want to do it off the condor grid (e.g. with more RAM). Default 0.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_postpone_submit</strong>: Integer. Debugging tool. If 1, the condor script is not submitted (useful for debugging). Default 0.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_pwd</strong>: String. Points the location of the “pwd” command, e.g. /bin/pwd, that is used in Condor launch scripts. This is set automatically on the submit machine, so if it is different on the nodes, you should set it manually.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_q</strong>: String. The Condor_q command, usually “/usr/bin/condor_q” but will depend on your HTCondor installation.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_requirements</strong>: String. Condor job requirements. These are passed to Condor directly, you should read the HTCondor manual to learn about this. If no requirements exist, leave as an string.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_should_transfer_files</strong>: Integer. Condor’s option to transfer files at the end of the job. You should set this to “YES”</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_snapshot_on_kill</strong>: Integer. If 1 we save a snapshot on SIGKILL before exit.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_stream_error</strong>: Boolean. If True, we activate Condor’s stderr stream. If False, this data is copied at the end of the job.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_stream_output</strong>: Boolean. If True, we activate Condor’s stdout stream. If False, this data is copied at the end of the job.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_submit</strong>: String. The Condor_submit command, usually “/usr/bin/condor_submit” but will depend on your HTCondor installation.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_universe</strong>: String. The HTCondor “universe”: this is “vanilla” by default.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_warn_max_memory</strong>: Integer. In MB, the memory use (ImageSize) of the job.</div>
</div>
<div class="line-block">
<div class="line"><strong>condor_when_to_transfer_output</strong>: Integer. Condor’s option to decide when output files are transferred. You should usually set this to “ON_EXIT_OR_EVICT”</div>
</div>
<div class="line-block">
<div class="line"><strong>custom_generator</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>custom_logging_func_memaddr</strong>: Memory address where the custom_logging_function is stored. Input: int</div>
</div>
<div class="line-block">
<div class="line"><strong>do_analytics</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>do_dry_run</strong>: Whether to do a dry run to calculate the total probability for this run</div>
</div>
<div class="line-block">
<div class="line"><strong>dry_run_hook</strong>: Function hook to be called for every system in a dry run. The function is passed a dict of the system parameters. Does nothing if None (the default).</div>
</div>
<div class="line-block">
<div class="line"><strong>dry_run_num_cores</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>ensemble_factor_in_probability_weighted_mass</strong>: Flag to multiply all the ensemble results with 1/probability_weighted_mass</div>
</div>
<div class="line-block">
<div class="line"><strong>evolution_type</strong>: Variable containing the type of evolution used of the grid. Multiprocessing, linear processing or possibly something else (e.g. for Slurm or Condor).</div>
</div>
<div class="line-block">
<div class="line"><strong>exit_after_dry_run</strong>: If True, exits after a dry run. Default is False.</div>
</div>
<div class="line-block">
<div class="line"><strong>exit_code</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>failed_systems_threshold</strong>: Variable storing the maximum number of systems that are allowed to fail before logging their command line arguments to failed_systems log files</div>
</div>
<div class="line-block">
<div class="line"><strong>function_cache</strong>: Boolean, default True. If True, we use a cache for certain function calls.</div>
</div>
<div class="line-block">
<div class="line"><strong>function_cache_TTL</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>function_cache_default_maxsize</strong>: Integer, default 256. The default maxsize of the cache. Should be a power of 2.</div>
</div>
<div class="line-block">
<div class="line"><strong>function_cache_default_type</strong>: String. One of the following types: LRUCache, LFUCache, FIFOCache, MRUCache, RRCache, TTLCache, NullCache, NoCache. You can find details of what these mean in the Python cachetools manual, except fo NoCache which means no cache is used at all, and NullCache is a dummy cache that never matches, used for testing overheads.</div>
</div>
<div class="line-block">
<div class="line"><strong>function_cache_functions</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>gridcode_filename</strong>: Filename for the grid code. Set and used by the population object. TODO: allow the user to provide their own function, rather than only a generated function.</div>
</div>
<div class="line-block">
<div class="line"><strong>joinlist</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>log_args</strong>: Boolean to log the arguments.</div>
</div>
<div class="line-block">
<div class="line"><strong>log_args_dir</strong>: Directory to log the arguments to.</div>
</div>
<div class="line-block">
<div class="line"><strong>log_dt</strong>: Time between verbose logging output.</div>
</div>
<div class="line-block">
<div class="line"><strong>log_file</strong>: Log file for the population object. Unused</div>
</div>
<div class="line-block">
<div class="line"><strong>log_newline</strong>: Newline character used at the end of verbose logging statements. This is n (newline) by default, but x0d (carriage return) might also be what you want.</div>
</div>
<div class="line-block">
<div class="line"><strong>log_runtime_systems</strong>: Whether to log the runtime of the systems . Each systems run by the thread is logged to a file and is stored in the tmp_dir. (1 file per thread). Don’t use this if you are planning to run a lot of systems. This is mostly for debugging and finding systems that take long to run. Integer, default = 0. if value is 1 then the systems are logged</div>
</div>
<div class="line-block">
<div class="line"><strong>max_queue_size</strong>: Maximum size of the queue that is used to feed the processes. Don’t make this too big! Default: 1000. Input: int</div>
</div>
<div class="line-block">
<div class="line"><strong>modulo</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>multiplicity_fraction_function</strong>: Which multiplicity fraction function to use. 0: None, 1: Arenou 2010, 2: Rhagavan 2010, 3: Moe and di Stefano (2017) 2017</div>
</div>
<div class="line-block">
<div class="line"><strong>n_logging_stats</strong>: Number of logging statistics used to calculate time remaining (etc.). E.g., if you set this to 10 the previous 10 calls to the verbose log will be used to construct an estimate of the time remaining.</div>
</div>
<div class="line-block">
<div class="line"><strong>num_cores</strong>: The number of cores that the population grid will use. You can set this manually by entering an integer great than 0. When 0 uses all logical cores. When -1 uses all physical cores. Input: int</div>
</div>
<div class="line-block">
<div class="line"><strong>num_cores_available</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>original_command_line</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>original_submission_time</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>original_working_diretory</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>parse_function</strong>: Function that the user can provide to handle the output the binary_c. This function has to take the arguments (self, output). Its best not to return anything in this function, and just store stuff in the self.grid_results dictionary, or just output results to a file</div>
</div>
<div class="line-block">
<div class="line"><strong>print_stack_on_exit</strong>: If True, prints a stack trace when the population’s exit method is called.</div>
</div>
<div class="line-block">
<div class="line"><strong>repeat</strong>: Factor of how many times a system should be repeated. Consider the evolution splitting binary_c argument for supernovae kick repeating.</div>
</div>
<div class="line-block">
<div class="line"><strong>restore_from_snapshot_dir</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>restore_from_snapshot_file</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>return_after_dry_run</strong>: If True, return immediately after a dry run (and don’t run actual stars). Default is False.</div>
</div>
<div class="line-block">
<div class="line"><strong>run_zero_probability_system</strong>: Whether to run the zero probability systems. Default: True. Input: Boolean</div>
</div>
<div class="line-block">
<div class="line"><strong>rungrid</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>save_ensemble_chunks</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>save_population_object</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>save_snapshots</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm</strong>: Integer flag used to control Slurm jobs. Default is 0 which means no Slurm. 1 means launch Slurm jobs. Do not manually set this to 2 (run Slurm jobs) or 3 (join Slurm job data) unless you know what you are doing, this is usually done for you.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_array</strong>: String. Override for Slurm’s –array option, useful for rerunning jobs manually. Default None.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_array_max_jobs</strong>: Integer. Override for the max number of concurrent Slurm array jobs. Default None.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_bash</strong>: String. Points the location of the “bash” command, e.g. /bin/bash, that is used in Slurm scripts. This is set automatically on the submit machine, so if it is different on the nodes, you should set it manually.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_date</strong>: String. Points the location of the “date” command, e.g. /usr/bin/date, that is used in Slurm scripts. This is set automatically on the submit machine, so if it is different on the nodes, you should set it manually.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_dir</strong>: String. Working directory containing e.g. scripts, output, logs (e.g. should be NFS available to all jobs). This directory should not exist when you launch the Slurm jobs.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_env</strong>: String. Points the location of the “env” command, e.g. /usr/bin/env or /bin/env, that is used in Slurm scripts. This is set automatically on the submit machine, so if it is different on the nodes, you should set it manually.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_extra_settings</strong>: Dictionary of extra settings for Slurm to put in its launch script. Please see the Slurm documentation for the many options that are available to you.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_jobarrayindex</strong>: Integer. Slurm job array index. Each job is numbered &lt;slurm_jobid&gt;.&lt;slurm_jobarrayindex&gt;.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_jobid</strong>: Integer. Slurm job id. Each job is numbered &lt;slurm_jobid&gt;.&lt;slurm_jobarrayindex&gt;.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_jobname</strong>: String which names the Slurm jobs, default “binary_c-python”.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_memory</strong>: String. Memory required for the job. Should be in megabytes in a format that Slurm understands, e.g. “512MB” (the default).</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_njobs</strong>: Integer. Number of Slurm jobs to be launched.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_ntasks</strong>: Integer. Number of CPUs required per array job: usually only need this to be 1 (the default).</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_partition</strong>: String containing the Slurm partition name. You should check your local Slurm installation to find out partition information, e.g. using the sview command.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_postpone_join</strong>: Integer, default 0. If 1 do not join job results with Slurm, instead you have to do it later manually.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_postpone_sbatch</strong>: Integer, default 0. If set to 1, do not launch Slurm jobs with sbatch, just make the scripts that would have.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_pwd</strong>: String. Points the location of the “pwd” command, e.g. /bin/pwd, that is used in Slurm scripts. This is set automatically on the submit machine, so if it is different on the nodes, you should set it manually.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_sbatch</strong>: String. The Slurm “sbatch” submission command, usually “/usr/bin/sbatch” but will depend on your Slurm installation. By default is set automatically.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_time</strong>: String. The time a Slurm job is allowed to take. Default is 0 which means no limit. Please check the Slurm documentation for required format of this option.</div>
</div>
<div class="line-block">
<div class="line"><strong>slurm_warn_max_memory</strong>: String. If we set slurm_memory in excess of this, warn the user because this is usually a mistake. Default “1024MB”.</div>
</div>
<div class="line-block">
<div class="line"><strong>source_file_filename</strong>: Variable containing the source file containing lines of binary_c command line calls. These all have to start with binary_c.</div>
</div>
<div class="line-block">
<div class="line"><strong>start_at</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>start_time</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>status_dir</strong>: Directory where grid status is stored</div>
</div>
<div class="line-block">
<div class="line"><strong>stop_queue</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>symlink_latest_gridcode</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>tmp_dir</strong>: Directory where certain types of output are stored. The grid code is stored in that directory, as well as the custom logging libraries. Log files and other diagnostics will usually be written to this location, unless specified otherwise</div>
</div>
<div class="line-block">
<div class="line"><strong>verbosity</strong>: Verbosity of the population code. Default is 0, by which only errors will be printed. Higher values will show more output, which is good for debugging.</div>
</div>
<div class="line-block">
<div class="line"><strong>weight</strong>: Weight factor for each system. The calculated probability is multiplied by this. If the user wants each system to be repeated several times, then this variable should not be changed, rather change the _repeat variable instead, as that handles the reduction in probability per system. This is useful for systems that have a process with some random element in it.</div>
</div>
<div class="line-block">
<div class="line"><strong>working_diretory</strong>: No description available yet</div>
</div>
</section>
<section id="moe-di-stefano-sampler-options">
<h2>Moe &amp; di Stefano sampler options<a class="headerlink" href="#moe-di-stefano-sampler-options" title="Permalink to this headline"></a></h2>
<p>The following options are meant to be changed by the user.</p>
<div class="line-block">
<div class="line"><strong>JSON</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>Mmin</strong>: Minimum stellar mass</div>
</div>
<div class="line-block">
<div class="line"><strong>multiplicity_model</strong>:
multiplicity model (as a function of log10M1)</div>
</div>
<blockquote>
<div><p>You can use ‘Poisson’ which uses the system multiplicity
given by Moe and maps this to single/binary/triple/quad
fractions.</p>
<p>Alternatively, ‘data’ takes the fractions directly
from the data, but then triples and quadruples are
combined (and there are NO quadruples).</p>
</div></blockquote>
<div class="line-block">
<div class="line"><strong>multiplicity_modulator</strong>:
[single, binary, triple, quadruple]</div>
</div>
<blockquote>
<div><dl class="simple">
<dt>e.g. [1,0,0,0] for single stars only</dt><dd><p>[0,1,0,0] for binary stars only</p>
</dd>
</dl>
<p>defaults to [1,1,0,0] i.e. singles and binaries</p>
</div></blockquote>
<div class="line-block">
<div class="line"><strong>normalize_multiplicities</strong>:
‘norm’: normalise so the whole population is 1.0
        after implementing the appropriate fractions
        S/(S+B+T+Q), B/(S+B+T+Q), T/(S+B+T+Q), Q/(S+B+T+Q)
        given a mix of multiplicities, you can either (noting that
        here (S,B,T,Q) = appropriate modulator * model(S,B,T,Q) )
        note: if you only set one multiplicity_modulator
        to 1, and all the others to 0, then normalising
        will mean that you effectively have the same number
        of stars as single, binary, triple or quad (whichever
        is non-zero) i.e. the multiplicity fraction is ignored.
        This is probably not useful except for
        testing purposes or comparing to old grids.</div>
</div>
<blockquote>
<div><dl>
<dt>‘raw’<span class="classifier">stick to what is predicted, i.e.</span></dt><dd><p>S/(S+B+T+Q), B/(S+B+T+Q), T/(S+B+T+Q), Q/(S+B+T+Q)
without normalisation
(in which case the total probability &lt; 1.0 unless
all you use single, binary, triple and quadruple)</p>
</dd>
<dt>‘merge’<span class="classifier">e.g. if you only have single and binary,</span></dt><dd><p>add the triples and quadruples to the binaries, so
binaries represent all multiple systems
…
<strong>* this is canonical binary population synthesis *</strong></p>
<p>It only takes the maximum multiplicity into account,
i.e. it doesn’t multiply the resulting array by the multiplicity modulator again.
This prevents the resulting array to always be 1 if only 1 multiplicity modulator element is nonzero</p>
<p>Note: if multiplicity_modulator == [1,1,1,1]. this option does nothing (equivalent to ‘raw’).</p>
</dd>
</dl>
</div></blockquote>
<div class="line-block">
<div class="line"><strong>q_high_extrapolation_method</strong>: Same as q_low_extrapolation_method</div>
</div>
<div class="line-block">
<div class="line"><strong>q_low_extrapolation_method</strong>:
q extrapolation (below 0.15) method
    none
    flat
    linear2
    plaw2
    nolowq</div>
</div>
<div class="line-block">
<div class="line"><strong>ranges</strong>:</div>
</div>
<div class="line-block">
<div class="line"><strong>resolutions</strong>:</div>
</div>
<div class="line-block">
<div class="line"><strong>samplerfuncs</strong>: No description available yet</div>
</div>
</section>
<section id="private-options">
<h2>Private options<a class="headerlink" href="#private-options" title="Permalink to this headline"></a></h2>
<p>The following options are not meant to be changed by the user, as these options are used and set internally by the object itself. The description still is provided, but just for documentation purposes.</p>
<div class="line-block">
<div class="line"><strong>_Moe2017_JSON_data</strong>: Location to store the loaded Moe&amp;diStefano2017 dataset</div>
</div>
<div class="line-block">
<div class="line"><strong>_actually_evolve_system</strong>: Whether to actually evolve the systems of just act as if. for testing. used in _process_run_population_grid</div>
</div>
<div class="line-block">
<div class="line"><strong>_binary_c_config_executable</strong>: Full path of the binary_c-config executable. This options is not used in the population object.</div>
</div>
<div class="line-block">
<div class="line"><strong>_binary_c_dir</strong>: Director where binary_c is stored. This options are not really used</div>
</div>
<div class="line-block">
<div class="line"><strong>_binary_c_executable</strong>: Full path to the binary_c executable. This options is not used in the population object.</div>
</div>
<div class="line-block">
<div class="line"><strong>_binary_c_shared_library</strong>: Full path to the libbinary_c file. This options is not used in the population object</div>
</div>
<div class="line-block">
<div class="line"><strong>_commandline_input</strong>: String containing the arguments passed to the population object via the command line. Set and used by the population object.</div>
</div>
<div class="line-block">
<div class="line"><strong>_count</strong>: Counter tracking which system the generator is on.</div>
</div>
<div class="line-block">
<div class="line"><strong>_custom_logging_shared_library_file</strong>: filename for the custom_logging shared library. Used and set by the population object</div>
</div>
<div class="line-block">
<div class="line"><strong>_end_time_evolution</strong>: Variable storing the end timestamp of the population evolution. Set by the object itself</div>
</div>
<div class="line-block">
<div class="line"><strong>_errors_exceeded</strong>: Variable storing a Boolean flag whether the number of errors was higher than the set threshold (failed_systems_threshold). If True, then the command line arguments of the failing systems will not be stored in the failed_system_log files.</div>
</div>
<div class="line-block">
<div class="line"><strong>_errors_found</strong>: Variable storing a Boolean flag whether errors by binary_c are encountered.</div>
</div>
<div class="line-block">
<div class="line"><strong>_evolution_type_options</strong>: List containing the evolution type options.</div>
</div>
<div class="line-block">
<div class="line"><strong>_failed_count</strong>: Variable storing the number of failed systems.</div>
</div>
<div class="line-block">
<div class="line"><strong>_failed_prob</strong>: Variable storing the total probability of all the failed systems</div>
</div>
<div class="line-block">
<div class="line"><strong>_failed_systems_error_codes</strong>: List storing the unique error codes raised by binary_c of the failed systems</div>
</div>
<div class="line-block">
<div class="line"><strong>_grid_variables</strong>: Dictionary storing the grid_variables. These contain properties which are accessed by the _generate_grid_code function</div>
</div>
<div class="line-block">
<div class="line"><strong>_killed</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>_loaded_Moe2017_data</strong>: Internal variable storing whether the Moe and di Stefano (2017) data has been loaded into memory</div>
</div>
<div class="line-block">
<div class="line"><strong>_main_pid</strong>: Main process ID of the master process. Used and set by the population object.</div>
</div>
<div class="line-block">
<div class="line"><strong>_population_id</strong>: Variable storing a unique 32-char hex string.</div>
</div>
<div class="line-block">
<div class="line"><strong>_probtot</strong>: Total probability of the population.</div>
</div>
<div class="line-block">
<div class="line"><strong>_queue_done</strong>: No description available yet</div>
</div>
<div class="line-block">
<div class="line"><strong>_set_Moe2017_grid</strong>: Internal flag whether the Moe and di Stefano (2017) grid has been loaded</div>
</div>
<div class="line-block">
<div class="line"><strong>_start_time_evolution</strong>: Variable storing the start timestamp of the population evolution. Set by the object itself.</div>
</div>
<div class="line-block">
<div class="line"><strong>_store_memaddr</strong>: Memory address of the store object for binary_c.</div>
</div>
<div class="line-block">
<div class="line"><strong>_system_generator</strong>: Function object that contains the system generator function. This can be from a grid, or a source file, or a Monte Carlo grid.</div>
</div>
<div class="line-block">
<div class="line"><strong>_total_mass_run</strong>: To count the total mass that thread/process has ran</div>
</div>
<div class="line-block">
<div class="line"><strong>_total_probability_weighted_mass_run</strong>: To count the total mass * probability for each system that thread/process has ran</div>
</div>
<div class="line-block">
<div class="line"><strong>_total_starcount</strong>: Variable storing the total number of systems in the generator. Used and set by the population object.</div>
</div>
<div class="line-block">
<div class="line"><strong>_zero_prob_stars_skipped</strong>: Internal counter to track how many systems are skipped because they have 0 probability</div>
</div>
</section>
</section>


           </div>
          </div>
          <footer><div class="rst-footer-buttons" role="navigation" aria-label="Footer">
        <a href="binary_c_parameters.html" class="btn btn-neutral float-left" title="Binary_c parameters" accesskey="p" rel="prev"><span class="fa fa-arrow-circle-left" aria-hidden="true"></span> Previous</a>
    </div>

  <hr/>

  <div role="contentinfo">
    <p>&#169; Copyright 2021, David Hendriks, Robert Izzard.</p>
  </div>

  Built with <a href="https://www.sphinx-doc.org/">Sphinx</a> using a
    <a href="https://github.com/readthedocs/sphinx_rtd_theme">theme</a>
    provided by <a href="https://readthedocs.org">Read the Docs</a>.
  
<br><br>
Generated on binarycpython git branch: development_0.9.3/2.2.1 git revision 65c361290c607d015366bca40731b634b361cfa0 url: <a href="https://gitlab.surrey.ac.uk/ri0005/binary_c-python/-/tree/development_0.9.3/2.2.1">git url</a>.
<br><br>
Using binary_c with bit branch branch_david: git revision: "5845:20220107:201620bd7" url: <a href="https://gitlab.surrey.ac.uk/ri0005/binary_c/-/tree/branch_david">git url</a>.



</footer>
        </div>
      </div>
    </section>
  </div>
  <script>
      jQuery(function () {
          SphinxRtdTheme.Navigation.enable(true);
      });
  </script> 

</body>
</html>