Re: Another question related to complete absorption models
Hi Stuart, I think the MPM2020 code follows the paper fairly well. (Any discrepancies from the paper should be considered bugs.) Perhaps the naming of the MPM2020 code is wrong, and it should instead be named something like MTR2020 (Makarov, Tretyakov, and Rosenkranz, 2020). Anyways, I would think that it is good to keep my code around as it tries to emulate the paper, even if this is kept with a different name. If a user of Arts cares about tracing their citations down to proper sources (which I assume they do) then it should be clear that using your implementation means you have to qualify the citation to Makarov etal 2020 with "partly based on" or "a modified version of". If you use my implementation you can at least drop the "partly"/"modified" as the aim is different. (If also the numbers in the code you are using are different from the paper I hope my citing user will also be able to find out where these numbers are from. Line mixing very much couples all parameters together. Changing one parameter thus makes them all incompatible with the underlying principle of the paper, so my citing user would have to find a new source to cite.) With hope, //Richard Den tors 10 mars 2022 kl 17:00 skrev Fox, Stuart < stuart@metoffice.gov.uk>: > Great, thanks Richard. That makes sense – I’ll see how I get on. > > > > It occurs to me that the oxygen implementation is going to be rather > similar to your existing MPM2020 oxygen model, the main differences being: > >- The water vapour effect on line broadening >- The inclusion of some lines outside the 50-60GHz band >- Some very minor differences (although not just rounding) in the line >parameters, since I’m basing it on the Rosenkranz FORTRAN code for detailed >comparison with someone else’s calculations, and this seems to be >marginally different to what is in your MPM2020 code (which I assume is >taken direct from the Makarov paper?) > > > > Should we be attempting to avoid this type of semi-duplication, or is it > an acceptable thing to do? > > > > Stuart > > > > *From:* Richard Larsson > *Sent:* 10 March 2022 15:50 > *To:* Fox, Stuart > *Cc:* arts_dev.mi@lists.uni-hamburg.de > *Subject:* Re: Another question related to complete absorption models > > > > *This email was received from an external source. Always check sender > details, links & attachments.* > > Hi Stuart, > > > > The only two species (and this can be extended) that are passed to the > predefined models interface currently are O2 and H2O. (It is fairly easy > to add more molecules.) > > > > To walk through the interface as a user: > > > > In a call to propmat_clearskyAddPredefined in > m_predefined_absorption_models.cc, you are computing a type called > "Absorption::PredefinedModel::VMRS" and storing this to an instance "vmr". > > > > All computations happen inside a function named > "Absorption::PredefinedModel::compute", which gets "vmr" passed to it. > This function simply passes this instance along to a function in > predefined_absorption_models.cc called "compute_selection". > > > > In "compute_selection" the "vmr" instance is split into its components, so > you can pass both H2O VMR and O2 VMR along to some underlying function. > These are accessed here as "vmr.O2" and "vmr.H2O". > > > > So for your new predefined model, simply define it to take vmro2 and > vmrh2o as inputs. You anyways have to define how you interface with your > new function in the list in "compute_selection". In that definition, pass > along both vmr.O2 and vmr.H2O to the relevant positions. This should be > enough. > > > > With hope, > > //Richard > > > > > > > > Den tors 10 mars 2022 kl 16:07 skrev Fox, Stuart < > stuart@metoffice.gov.uk>: > > Hi ARTS developers, > > > > I’m trying to add the latest version of the Rosenkranz absorption models > into ARTS for a study we are currently doing. One of the “features” of the > model is that the oxygen absorption calculation has a dependence on the > water vapour density (due to the fact that the water vapour is more > efficient at line broadening than dry air). However, as far as I understand > it the oxygen absorption routine (under the “modern” system) will not get > passed the water vapour vmr. Is this correct, and is there any way around > this? > > > > Thanks, as always, for your help, > > > > Stuart > >
RE: Another question related to complete absorption models
Great, thanks Richard. That makes sense – I’ll see how I get on. It occurs to me that the oxygen implementation is going to be rather similar to your existing MPM2020 oxygen model, the main differences being: * The water vapour effect on line broadening * The inclusion of some lines outside the 50-60GHz band * Some very minor differences (although not just rounding) in the line parameters, since I’m basing it on the Rosenkranz FORTRAN code for detailed comparison with someone else’s calculations, and this seems to be marginally different to what is in your MPM2020 code (which I assume is taken direct from the Makarov paper?) Should we be attempting to avoid this type of semi-duplication, or is it an acceptable thing to do? Stuart From: Richard Larsson Sent: 10 March 2022 15:50 To: Fox, Stuart Cc: arts_dev.mi@lists.uni-hamburg.de Subject: Re: Another question related to complete absorption models This email was received from an external source. Always check sender details, links & attachments. Hi Stuart, The only two species (and this can be extended) that are passed to the predefined models interface currently are O2 and H2O. (It is fairly easy to add more molecules.) To walk through the interface as a user: In a call to propmat_clearskyAddPredefined in m_predefined_absorption_models.cc, you are computing a type called "Absorption::PredefinedModel::VMRS" and storing this to an instance "vmr". All computations happen inside a function named "Absorption::PredefinedModel::compute", which gets "vmr" passed to it. This function simply passes this instance along to a function in predefined_absorption_models.cc called "compute_selection". In "compute_selection" the "vmr" instance is split into its components, so you can pass both H2O VMR and O2 VMR along to some underlying function. These are accessed here as "vmr.O2" and "vmr.H2O". So for your new predefined model, simply define it to take vmro2 and vmrh2o as inputs. You anyways have to define how you interface with your new function in the list in "compute_selection". In that definition, pass along both vmr.O2 and vmr.H2O to the relevant positions. This should be enough. With hope, //Richard Den tors 10 mars 2022 kl 16:07 skrev Fox, Stuart mailto:stuart@metoffice.gov.uk>>: Hi ARTS developers, I’m trying to add the latest version of the Rosenkranz absorption models into ARTS for a study we are currently doing. One of the “features” of the model is that the oxygen absorption calculation has a dependence on the water vapour density (due to the fact that the water vapour is more efficient at line broadening than dry air). However, as far as I understand it the oxygen absorption routine (under the “modern” system) will not get passed the water vapour vmr. Is this correct, and is there any way around this? Thanks, as always, for your help, Stuart
Re: Another question related to complete absorption models
Hi Stuart, The only two species (and this can be extended) that are passed to the predefined models interface currently are O2 and H2O. (It is fairly easy to add more molecules.) To walk through the interface as a user: In a call to propmat_clearskyAddPredefined in m_predefined_absorption_models.cc, you are computing a type called "Absorption::PredefinedModel::VMRS" and storing this to an instance "vmr". All computations happen inside a function named "Absorption::PredefinedModel::compute", which gets "vmr" passed to it. This function simply passes this instance along to a function in predefined_absorption_models.cc called "compute_selection". In "compute_selection" the "vmr" instance is split into its components, so you can pass both H2O VMR and O2 VMR along to some underlying function. These are accessed here as "vmr.O2" and "vmr.H2O". So for your new predefined model, simply define it to take vmro2 and vmrh2o as inputs. You anyways have to define how you interface with your new function in the list in "compute_selection". In that definition, pass along both vmr.O2 and vmr.H2O to the relevant positions. This should be enough. With hope, //Richard Den tors 10 mars 2022 kl 16:07 skrev Fox, Stuart < stuart@metoffice.gov.uk>: > Hi ARTS developers, > > > > I’m trying to add the latest version of the Rosenkranz absorption models > into ARTS for a study we are currently doing. One of the “features” of the > model is that the oxygen absorption calculation has a dependence on the > water vapour density (due to the fact that the water vapour is more > efficient at line broadening than dry air). However, as far as I understand > it the oxygen absorption routine (under the “modern” system) will not get > passed the water vapour vmr. Is this correct, and is there any way around > this? > > > > Thanks, as always, for your help, > > > > Stuart >
Another question related to complete absorption models
Hi ARTS developers, I'm trying to add the latest version of the Rosenkranz absorption models into ARTS for a study we are currently doing. One of the "features" of the model is that the oxygen absorption calculation has a dependence on the water vapour density (due to the fact that the water vapour is more efficient at line broadening than dry air). However, as far as I understand it the oxygen absorption routine (under the "modern" system) will not get passed the water vapour vmr. Is this correct, and is there any way around this? Thanks, as always, for your help, Stuart
