Input File Format

Headers

The input file format is fairly simple to work with. The extension for Taurex3 input files is .par however this is generally not enforced by the code. The input is defined in various headers, with each header having variables that can be set:

[Header]
parameter1 = value
parameter2 = anothervalue

[Header2]
parameter1 = adifferentvalue

Of course comments are handled with #

Not all of these headers are required in an input file. Some will generate default profiles when not present. To perform retrievals, [Observation], [Optimizer] and [Fitting] MUST be present

Some of these may define additional subheaders given by the [[Name]] notation:

[Header]
parameter1 = value
    [[Subheader]]
    parameter2 = anothervalue

Variables

String variables take this form:

#This is valid
string_variable = Astringvariable
#This is also valid
string_variable_II = "A string variable"

Floats and ints are simply:

my_int_value = 10

And lists/arrays are defined using commas:

my_int_list = 10,20,30
my_float_list = 1.1,1.4,1.6,
my_string_list = hello,how,are,you

Dynamic variables

The input file is actually a dynamic format and its available variables can change depending on the choice of certain profiles and types. For example lets take the [Temperature] header, it contains the variable profile_type which describes which temperature profile to use. Setting this to isothermal gives us the T variable which defines the isothermal temeprature:

[Temperature]
profile_type = isothermal
T = 1500.0

Now if we change the profile type to guillot2010 it will use the Guillot 2010 temperature profile which gives access to the variables T_irr, kappa_irr, kappa_v1, kappa_v2 and alpha instead:

[Temperature]
profile_type = guillot2010
T_irr=1500
kappa_irr=0.05
kappa_v1=0.05
kappa_v2=0.05
alpha=0.005

However setting T will throw an error as it doesn’t exist anymore:

[Temperature]
profile_type = guillot2010
#Error is thrown here
T=1500
kappa_irr=0.05

This also applies to fitting parameters, profiles provide certain fitting parameters and changing the model means that these parameters may not exist anymore.

The [Model] block can also expand dynamically. A basic single-region setup might look like this:

[Model]
model_type = transmission

    [[Absorption]]

If you switch to the integrated multimodel support, the same section accepts composite-model keys such as parfiles and fractions:

[Model]
model_type = multi_transit
parfiles = day.par, night.par
fractions = 0.7

In that configuration TauREx reads one regional parameter file per entry in parfiles and combines the resulting spectra with the supplied weights. If you provide only N-1 fraction values, the final weight is inferred so that the total remains unity.

That change also expands the fitting-parameter surface. Composite models expose shared area-fraction parameters such as fr_1 and region-prefixed component parameters such as m1_T whenever profiles are not coupled between regions:

[Fitting]
fr_1:fit = True
m1_T:fit = True

The same pattern applies to model_type = multi_eclipse and model_type = multi_directimage.

The same expansion happens in the [Observation] block. A standard observation entry might look like this:

[Observation]
observed_spectrum = /path/to/data.dat

If instead you switch to the integrated multi-instrument loader, the accepted keys expand to include per-spectrum systematics controls:

[Observation]
observation = spectra_w_offsets
path_spectra = /path/spec_1.dat, /path/spec_2.dat
offsets = 0.0, 0.0
slopes = 0.0, 0.0
error_scale = 1.0, 1.0

That change also adds new fitting parameters such as Offset_1, Slope_1 and EScale_1 that can be configured in [Fitting]:

[Fitting]
Offset_1:fit = True
Slope_1:fit = True
EScale_1:fit = True

Using observation = spectra_instr extends the same pattern with optional broadening_profiles entries for wavelength-dependent convolution before the final binning stage.

Mixins

Added in version 3.1.

Mixins can be applied to any base component through the + operator:

[Temperature]
profile_type = mixin1+mixin2+base

Where we apply mixin1 and mixin2 to a base. Including mixins will also include their keywords as well. If mixin1 has the keyword param1, mixin2 has param2 and base has another_param then we can define in the input file:

[Temperature]
profile_type = mixin1+mixin2+base
param1 = "Hello"       # From mixin 1
param2 = "World"       # From mixin 2
another_param = 10.0   # From base

Mixins are evaluated in reverse, the last must be a non-mixin for example if we have a doubler mixin that doubles temperature profiles then this is valid:

[Temperature]
profile_type = doubler+isothermal

but this is not valid:

[Temperature]
profile_type = isothermal+doubler

Additionally we cannot have more than one base class so this is invalid:

[Temeprature]
profile_type = doubler+isothermal+guillot

The reverse evaluation means that the first mixin will be applied last. If we have another mixin called add50 which adds 50 K to the profile, then:

[Temperature]
profile_type = doubler+add50+isothermal
T = 1000

Will result in a temperature profile of \(2100~K\). If we instead do this:

[Temperature]
profile_type = add50+doubler+isothermal
T = 1000

Then the resultant temperature will be \(2050~K\).