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 >
