Hi Stefan, If we do something like this we have to start by removing abs_xsec_agenda. There's no good way to mold the Zeeman effect into fitting with it.
I will inline the rest. Den mån 1 feb. 2021 kl 17:29 skrev Stefan Buehler < stefan.bueh...@uni-hamburg.de>: > 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. > I do like this idea. It simplifies the interface significantly and users would no longer have to deal with setting up the Agendas. The "absorbers" would do that for them. This is similar to how you no longer have to deal with line catalog settings. It's a direction of development for ARTS that I like. > 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. > They do not have the same outputs. You ignore abs_xsec_agenda, and it has to go for this to work. I cannot see this working with multiple levels of absorption routines, since Zeeman and some others require polarization. The rest I have to say depends on abs_xsec_agenda going away. The tag system here is important. You have to have a full line catalog read when you start setting this up. Otherwise the frequency limited tags would not get their lines. And perhaps even the non-frequency limited tags would also get the frequency limited lines. It is therefore very important that the new "Absorber" class/list takes ownership of data from the line catalog. I guess having the data available ahead of time is important for all types of "Absorber"s (like CIA data and Xsec data and line mixing data). I think your way of "adding" many tags might become confusing. The Jacobian method requires an Array-tag of some kind for one of its ways to compute the VMR derivatives. From your water example, will that tag be "H2O,H2O-CKD-MT-3_7", just "H2O", or will either of the two tags work for that Jacobian VMR method? I am not sure what to do here. > 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. > Well, the lower level functions of the absorption routines allocates quite a lot of data. I am not sure if repeating these operations is expensive or not, but if you separate this more then they would be allocated not just once per atmospheric level but once per species and atmospheric level. As an example, these variables are being allocated over-and-over again for a call to the Zeeman routine: In propmat_clearskyAddZeeman: rtp_los (2 Numeric) In zeeman_on_the_fly: jacobian_quantities_positions (nq Index) scratch (4 * nf + 2 * nq * nf + 4 + 2 *nq Complex) sum (4 * nf + 2 * nq * nf + 4 + 2 *nq Complex) B (nf Numeric if non-lte is active otherwise 0) dBdT (nf Numeric if non-lte is active otherwise 0) line_shape_vmr (nb) Now I am not claiming that this is ideal, but for a standard run of 3 retrieval parameters and 65000 frequencies, without non-lte, that's something like 3 Mb (?) of quite often repeated allocations. At the very least, if the scratch+sum values, which are necessary compute parameters, would be kept as they are, this would be quite a lot less allocations having to happen. Note also how quickly this goes up if you try to compute more for the derivatives. Note that this is of course also the case for the absorption xsec agenda, where "Init" allocates a significant amount of memory, but I am not sure if these variables are kept around after an agenda closes down or not for the next call. If this is kept as a "model data" type, then those could easily be allocated only once per level. And if we are going with class-based computations, such 'invariants' should be used properly. It might make sense to have these invariants per entry of the Absorber class for simplicity though, so perhaps that's what we want to do? It would just be 3 Mb times the number of species anyways, so it's perhaps not that much if we keep it throughout the lifetime of the class (with an option to clear the data somehow). 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. > Sure, I agree this would be the way to go but with keeping some computational data around longer. > 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. > I don't like this either. I think that if the catalog and all absorption data is read ahead of initializing the "Absorber" class, you would solve this particular issue. The "Absorber" class has to be possible to write to file anyways, so it's fine to have the setup in this order since we would be able to save things for the another run anyways. Perhaps even be able to ship complete "Absorber" models instead of just "Absorber" line data. With hope, //Richard
