RampFitStep - accept integer values for maximum_cores (#8123)

Co-authored-by: Nadia Dencheva <[email protected]>

CHANGES.rst

@@ -148,6 +148,9 @@ ramp_fitting
 
 - Moving some ramp fitting CI tests from JWST to STCAL. [#8060]
 
+- Updated the argument description and parameter definition for `maximum_cores`
+  to accept integer values to be passed to STCAL ramp_fit.py. [#8123]
+
 resample
 --------
 

docs/jwst/ramp_fitting/arguments.rst

@@ -16,12 +16,14 @@ The ramp fitting step has three optional arguments that can be set by the user:
   which will compute all values for the ramp the same as if the entire ramp were
   saturated.
 
-* ``--maximum_cores``: The fraction of available cores that will be
-  used for multi-processing in this step. The default value is 'none' which does not use
-  multi-processing. The other options are 'quarter', 'half', and 'all'. Note that these
-  fractions refer to the total available cores and on most CPUs these include physical
-  and virtual cores. The clock time for the step is reduced
-  almost linearly by the number of physical cores used on all machines. For example, on an Intel CPU with
-  six real cores and 6 virtual cores setting maximum_cores to 'half' results in a
-  decrease of a factor of six in the clock time for the step to run. Depending on the system
+* ``--maximum_cores``: The number of available cores that will be
+  used for multi-processing in this step. The default value is '1' which does not use
+  multi-processing. The other options are either an integer, 'quarter', 'half', and 'all'.
+  Note that these fractions refer to the total available cores and on most CPUs these include
+  physical and virtual cores. The clock time for the step is reduced almost linearly by the
+  number of physical cores used on all machines. For example, on an Intel CPU with
+  six real cores and six virtual cores, setting maximum_cores to 'half' results in a
+  decrease of a factor of six in the clock time for the step to run. Depending on the system,
   the clock time can also decrease even more with maximum_cores is set to 'all'.
+  Setting the number of cores to an integer can be useful when running on machines with a
+  large number of cores where the user is limited in how many cores they can use.

jwst/ramp_fitting/ramp_fit_step.py

@@ -391,7 +391,7 @@ class RampFitStep(Step):
         save_opt = boolean(default=False) # Save optional output
         opt_name = string(default='')
         suppress_one_group = boolean(default=True)  # Suppress saturated ramps with good 0th group
-        maximum_cores = option('none', 'quarter', 'half', 'all', default='none') # max number of processes to create
+        maximum_cores = string(default='1') # cores for multiprocessing. Can be an integer, 'half', 'quarter', or 'all'
     """
 
     # Prior to 04/26/17, the following were also in the spec above:

jwst/ramp_fitting/tests/test_ramp_fit_step.py

@@ -14,6 +14,8 @@
 JUMP = test_dq_flags["JUMP_DET"]
 SAT = test_dq_flags["SATURATED"]
 
+MAXIMUM_CORES = ['2', 'none', 'quarter', 'half', 'all']
+
 
 @pytest.fixture(scope="module")
 def generate_miri_reffiles():
@@ -140,7 +142,8 @@ def setup_subarray_inputs(
     return model1, gdq, rnModel, pixdq, err, gain
 
 
-def test_ramp_fit_step(generate_miri_reffiles, setup_inputs):
+@pytest.mark.parametrize("max_cores", MAXIMUM_CORES)
+def test_ramp_fit_step(generate_miri_reffiles, setup_inputs, max_cores):
     """
     Create a simple input to instantiate RampFitStep and execute a call to test
     the step class and class method.
@@ -166,7 +169,7 @@ def test_ramp_fit_step(generate_miri_reffiles, setup_inputs):
     # Call ramp fit through the step class
     slopes, cube_model = RampFitStep.call(
         model, override_gain=override_gain, override_readnoise=override_readnoise,
-        maximum_cores="none")
+        maximum_cores=max_cores)
 
     assert slopes is not None
     assert cube_model is not None