Hej Richard,
to me the interesting point is that the specific inputs could be handled
where the “Add..Habit” happens. In the case of absorption, a lot of
difficulty comes from the dichotomy between the species tags and the
methods that have to be added to the absorption agenda to actually do
the calculations. Using Simons concept, one could potentially replace
the tags by something like
AbsorberAppendLBL(“H2O”)
AbsorberAppendCIA(“N2-O2”)
AbsorberAppendLBL(“O3”)
AbsorberAppendXsec(“CFC-11”)
So, instead of indentifying the model to be used by the tag name, we
could identify it by the Add method used. The different Add methods
would depend on different input variables, such as line catalog,
tabulated cross-sections, etc.. That solution seems quite elegant to me.
One problem is, though, that one absorption tag currently can be a
combination of models for the same gas species. One way to solve this
would be to have two types of methods, Add and Append, like this:
AbsorberAppendLBL(“H2O”)
AbsorberAddCont(“H2O”,”CKD-MT-3_7)
AbsorberAppendCIA(“N2-O2”)
AbsorberAppendLBL(“O2”)
AbsorberAddCont(“O2”,”PWR20”)
AbsorberAppendXsec(“CFC-11”)
A strict interface for the output is no problem, since all absorption
functions produce exactly the same output.
For the (atmospheric) input it is potentially more problematic. For
example, Zeeman absorption depends on the magnetic field, but none of
the other absorption functions do.
I don’t think there is so much overhead that one really gains a lot by
for example doing all the LBL species in one go. One could basically use
the present lower level functions, and just call them repeatedly for
each gas in turn. When the absorption lookup table is generated, I think
it is already done this way.
AbsorberAppendLBL would depend on abs_lines_per_species, and just
incorporate the lines for the species in questions to the local data of
the AbsorberLBL class, inheriting the public interface from the general
Absorber class.
So, I think in principle this structure could be built on top of the
various absorption functions we have, replacing the current tag
mechanism.
Ah, there probably are a lot of pitfalls.
One that I just noticed is that, if the species list is only established
by these Append methods, then we have no good way to decide for which
species we should read in the line catalogue data. (For that the list of
species of interest would have to be defined before.) This could be
solved by the Append method doing the catalog reading, but that would
make the Append methods quite heavy. On the other hand it would make for
very short and simple controlfiles, the call would be like:
AbsorberAppendLBL(<catalog_basename>,“H2O”)
I’m not sure whether I like that, though, it seems less flexible than
what we have when it comes to dealing with the catalog.
All the best,
Stefan
On 1 Feb 2021, at 16:10, Richard Larsson wrote:
Simon, Stefan,
It seems to me that this is a proposal of using a modern "void *"
list/vector with some strict interface. Have I misunderstood
something
here? I mean you might implement it with virtual classes,
std::variant, or
some other reinterpreting interface but that seems about it.
I am not going to argue for the scattering implementation here because
I
assume you guys know the current interface well enough and have ideas
of
how to easily extend it using the new and old methods. Perhaps the
strict
interface helps here.
I would not mind having a "void *" list/vector in the LBL code but I
am
very wary about the strict interface requirements here. I would be
much
more accepting if we could just get some kind of "const ClassImpl&"
back
from the "void *" list. Then the different methods can much more
easily
know if they need to write to src or not, to a PropagationMatrix
interface
or to an ArrayOfMatrix interface.
I don't like the idea of separating this by species in the LBL though.
It
would be much better to separate it by the types of calculations
necessary
(the SpeciesTag-enum + the Absorption::PopulationType enum for LBL).
That
way you could probably allow pre-allocations of all allocated
variables
used by the algorithms taking the class without having to worry too
much
about the memory footprint and leaving deallocation or reuse up to the
user
(a cleanup method or more in the Agenda).
That said, I think it is quite a daunting task to change things this
way.
And I am not sure how easy it is to take Simon's idea and use it with
value-semantics.
With hope,
//Richard
Den mån 1 feb. 2021 kl 14:14 skrev Stefan Buehler <
stefan.bueh...@uni-hamburg.de>:
Dear Simon,
The handling of the constant data is completely up to the
implementation of the specific scatterers.
For the ScatteringParticle class, for example, this is provided when
the object is constructed.
So when the ARTS user calls:
scattering_speciesAddScatteringHabit(...)
an object is created which will hold the scattering data. It will
then
use it when asked to
compute the bulk scattering properties. Since the
calculate_bulk_properties(...) method
is called on this object, it automatically has access to the
required
data.
Ah, yes. That is a great solution. Perhaps I could do the same for
the
absorbers. But I would have to break up the methods so that they are
standalone for each absorption tag. Right now, the method that does
LBL,
for example, will calculate for all the LBL absorption tags, using a
common workspace variable for the line catalog (which is internally
split by species). All the housekeeping around this is a lot of
trouble.
Perhaps it would be better to always run it just for a single
absorber,
and use a technique similar to yours to set up the list, so that each
absorber gets the line list he needs. (And similarly for the other
types
of absorption.)
/Stefan
