Re: [arts-users] consultancy question
Hi ZhangChao, > > > > Secondly,the HITRAN database has a clearly defined purpose for its use, > > whereas Perrin, which is frequently utilized, has a mixed source,could > > you have a reference for this? > > For AMSU and to get started, it is easier to use some of the predined > absorption models for O2, N2 and H2O, by e.g. Rosenkranz. > > The Perrin catalogue is targeted at microwave applications in (general) planetary atmospheres. The reference for this data is the ARTS 2.2 paper ( https://doi.org/10.5194/gmd-11-1537-2018) with details given in the therein referenced technical report (Mendrok & Eriksson, 2014). However, as Patrick pointed out, for applications in Earth atmosphere full absorption models like the Rosenkranz or Liebe models (in contrast to line-by-line calculations) are most of the time the more suitable (and easier to apply) choice. Best, -- Jana Mendrok, Ph.D. Deutscher Wetterdienst Offenbach am Main, Germany +49 (0)69 8062 3139
Re: [arts-users] R: Cannot create abs_lookup with arts 2.5
>
> >>
>
> >>
>
> >>
>
> >>
>
> >>
>
> >> Pengwang Zhai ha scritto:
>
> >>
>
> >>> Thanks, Mattia. Would you advise how TestAbs.arts can be revised to
> include line-by-line calculation?
>
> >>>
>
> >>> Note that the behavior of TestAbs.arts is different in arts2.3, which
> does calculate line-by-line absorption coefficients.
>
> >>>
>
> >>> I do not want continua, as I am mainly interested in the visible
> spectra, which is out of most of those continuum models. Based on my
> experience with previous arts version, arts does not check the spectrum
> limits for the continuum models. I am not sure whether arts 2.5 has been
> improved on this.
>
> >>>
>
> >>> Pengwang
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>>> On Feb 10, 2022, at 9:46 AM, mattia.sabat...@artov.ismar.cnr.it
> wrote:
>
> >>>>
>
> >>>> Hi Pengwang,
>
> >>>>
>
> >>>> the controlfile TestAbs.arts, in line 15, has the following:
>
> >>>> Copy(abs_xsec_agenda, abs_xsec_agenda__noCIA)
>
> >>>>
>
> >>>> I checked in controlfiles/general/agendas.arts for what
> abs_xsec_agenda__noCIA does:
>
> >>>> AgendaCreate( abs_xsec_agenda__noCIA )
>
> >>>> AgendaSet( abs_xsec_agenda__noCIA ){
>
> >>>> abs_xsec_per_speciesInit
>
> >>>> abs_xsec_per_speciesAddConts
>
> >>>> }
>
> >>>>
>
> >>>> Therefore the agenda calculates absorption for continua tag only (see
> https://atmtools.github.io/arts-docs-master/docserver/methods/abs_xsec_per_speciesAddConts.html).
> You selected H2O, and by doing this my guess is that you are not
> considering continuum, as it is written in lines 36-37 of TestAbs.arts.
>
> >>>>
>
> >>>> I hope that this will help you,
>
> >>>>
>
> >>>> Mattia
>
> >>>>
>
> >>>>
>
> >>>> Pengwang Zhai ha scritto:
>
> >>>>
>
> >>>>> Hello, ARTS community,
>
> >>>>>
>
> >>>>> I downloaded and compiled the latest version of arts. Now I tested
> the the creation of abs_lookup with the example control file located in:
>
> >>>>>
>
> >>>>> arts/controlfiles/artscomponents/absorption/TestAbs.arts
>
> >>>>>
>
> >>>>> I only modified two occurrences of:
>
> >>>>>
>
> >>>>> abs_speciesSet( species=[ "H2O-PWR98",
>
> >>>>>"O2-PWR93",
>
> >>>>>"N2-SelfContStandardType" ] )
>
> >>>>>
>
> >>>>> to:
>
> >>>>>
>
> >>>>> abs_speciesSet( species=[ "H2O" ] )
>
> >>>>>
>
> >>>>> and run
>
> >>>>>
>
> >>>>> arts TestAbs.arts
>
> >>>>>
>
> >>>>> The resultant abs_lookup are all ZEROs.
>
> >>>>>
>
> >>>>> Any help?
>
> >>>>>
>
> >>>>> More background information: I used arts 2.3 to create abs_lookup
> for H2O, CO2, etc. in the visible by reading from HITRAN 2012. The baseline
> example was TestAbs.arts provided by the arts installation. Now I need to
> revisit the calculation based on HITRAN 2020, and the lookup table
> calculation seems not working with arts 2.5. I greatly appreciate it if you
> could provide a working example on how to create a abs_lookup with arts 2.5.
>
> >>>>>
>
> >>>>> Pengwang
>
> >
>
>
>
>
> ___
> arts_users.mi mailing list
> arts_users.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
>
--
Jana Mendrok, Ph.D.
Deutscher Wetterdienst
Offenbach am Main, Germany
+49 (0)69 8062 3139
___
arts_users.mi mailing list
arts_users.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] Issues with size interpolation - ARTS SSD
Hi Patrick et al, on the same set of grids. That is, the idea is to use these functions > first, before any size interpolation. This is at least indicated in the > documentation of assp_interp_size.m. > > > No time for me to dig into the Python code (and anyhow don't have the > latest version at hand), and don't remember how closely Jana mimicked my > Matlab interface. Used to follow the Matlab implementation very closely. An assp_interp_za exists. However, it's obviously nowhere applied (in the original Zenodo published version; I did not check out newer ones). The header of assp_interp_size states the need for common grids. Though I agree, that's not very prominently, hence easily missed by a user and definitely missed when not called directly by the user. Obviously, assp_interp_size misses a proper check that this requirement is fulfilled... I guess, back in the days all size instances of one habit had the same number of angles, so it wasn't necessary to apply that (what speaks for that is that an IconSnow.rssp file exists; and that had been created with exactly the code that was published, ie without az-interpolation). Isaac/Vasileios - get_assp hence needs to be extended with a call of assp_interp_za, in between the assp_import_ssdb and assp.assp_interp_size (not deep enough into it anymore to judge whether exact location matters...). In any case, Vasileios, thanks for caring for the code (and cleaning up after me)! Best, -- Jana Mendrok, Ph.D. Deutscher Wetterdienst Offenbach am Main, Germany +49 (0)69 8062 3139 ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] atm.scenario & cov-mat issues
Oh, right. my bad. Sx is the apriori, not the retrieval error *facepalm* Thanks, Simon! On Thu, Nov 28, 2019 at 7:55 AM Simon Pfreundschuh < simon.pfreundsc...@chalmers.se> wrote: > > The covmat_sx is output (as far as my little OEM knowledge goes). And as > a curious user, I of course like to know what is in my output/what's the > meaning of my output (and not just half of it. > particularly when it makes > me getting unsure, whether I use the right part of this > larger-than-expected output variable) ;) > > looking forward to the next release then! :) > > > This is not true though. The particular covariance matrix format is used > only for the input covariance matrices. > > The ones that can be considered output (covmat_ss, covmat_so) are > generally dense so there's nothing to be gained > > in representing them as block-diagonal matrices. > > > Cheers, > > > Simon > -- > *From:* Jana Mendrok > *Sent:* Wednesday, November 27, 2019 7:42:26 PM > *To:* Simon Pfreundschuh > *Cc:* Rita Kajtar; arts_users...@mailman.rrz.uni-hamburg.de > *Subject:* Re: [arts-users] atm.scenario & cov-mat issues > > Hi Simon, hi all, > > >> I might have expressed myself not very clearly but I remain convinced >> that the assertion >> >> is caused by the pressure retrieval grid. The smallest value in it is >> smaller than that in >> >> the pressure grid. This is similar but unrelated to the first error where >> the p_grid extended >> >> out of the range of the raw p_grid. >> > I see (I indeed misunderstood you before. Sorry.). > > I agree, this then should be caught by an error (with a proper error > message). > > >> Regarding covariance matrices: There is currently no extensive >> documentation for covariance matrices >> >> but documentation of workspace groups is something that we are working on >> for the next release. >> >> Anyhow, the user in general does not have to worry about the inverse >> blocks if she doesn't want to set >> >> them explicitly. >> > The covmat_sx is output (as far as my little OEM knowledge goes). And as a > curious user, I of course like to know what is in my output/what's the > meaning of my output (and not just half of it. particularly when it makes > me getting unsure, whether I use the right part of this > larger-than-expected output variable) ;) > looking forward to the next release then! :) > > Finally, there was another bug in the loading of the covariance matrices >> from xml files, which caused >> >> the behavior that you were describing. This one is fixed now in the >> development version of typhon. >> > Ok, thanks! > > Regards, > Jana > > > > -- > Jana Mendrok, Ph.D. > Deutscher Wetterdienst > Offenbach am Main, Germany > > +49 (0)69 8062 3139 > -- Jana Mendrok, Ph.D. Deutscher Wetterdienst Offenbach am Main, Germany +49 (0)69 8062 3139 ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] atm.scenario & cov-mat issues
Hi Simon, hi all, > I might have expressed myself not very clearly but I remain convinced that > the assertion > > is caused by the pressure retrieval grid. The smallest value in it is > smaller than that in > > the pressure grid. This is similar but unrelated to the first error where > the p_grid extended > > out of the range of the raw p_grid. > I see (I indeed misunderstood you before. Sorry.). I agree, this then should be caught by an error (with a proper error message). > Regarding covariance matrices: There is currently no extensive > documentation for covariance matrices > > but documentation of workspace groups is something that we are working on > for the next release. > > Anyhow, the user in general does not have to worry about the inverse > blocks if she doesn't want to set > > them explicitly. > The covmat_sx is output (as far as my little OEM knowledge goes). And as a curious user, I of course like to know what is in my output/what's the meaning of my output (and not just half of it. particularly when it makes me getting unsure, whether I use the right part of this larger-than-expected output variable) ;) looking forward to the next release then! :) Finally, there was another bug in the loading of the covariance matrices > from xml files, which caused > > the behavior that you were describing. This one is fixed now in the > development version of typhon. > Ok, thanks! Regards, Jana -- Jana Mendrok, Ph.D. Deutscher Wetterdienst Offenbach am Main, Germany +49 (0)69 8062 3139 ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] atm.scenario & cov-mat issues
Hi Simon, hi all, the (p_grid) error is irrelevant (it is caught, it got fixed). The ASSERTION is the issue. It occurs once TestOEM.arts' default atmosphere (tropical standard atmo from AFGL/Fascode) is replaced with the subarctic winter AFGL/Fascode atmosphere (and the p_grid setting suitably adapted). Regarding the covariance matrix... First, I think it should occur in the documentation that covmat_sx contains the blocks and their inverse (does that also mean the inverse blocks together form the complete inverse Sx? Sorry, my instantaneous vector math knowledge is not good enough to judge that myself :( ). Did we just miss tzhat piece of information or is it not in the docs (yet)? Second, Rita reads covmat_sx in from xml file using typhon.arts.xml.load. Would that be the same as the ws.covmat_sx in your example? I had the feeling something went wrong there, too. typhon did not complain, but len(covmat_sx.blocks) was 0 (the read-in file contained the mentioned 6 blocks). Thanks & regards, Jana On Wed, Nov 27, 2019 at 9:47 AM Simon Pfreundschuh < simon.pfreundsc...@chalmers.se> wrote: > Hi Rita, > > > The error you get is because your retrieval pressure grid extends higher > up than > > your atmospheric grid. Indeed, this error should be caught but I have to > see with > > the others how this can be done most effectively. > > > Regarding the covariance matrix: The covariance matrix contains 6 blocks > because > > for each retrieval quantity, i.e. for O3, freq. shift, and Polyfit, two > blocks are added. > > It's two because the inverses of the blocks are pre-computed and included > in the > > covariance matrix. > > > In Python, you can access the blocks of the covariance matrix over the > 'blocks' > > attribute which contains one element for each retrieval quantity (their > inverses > > are stored in the 'inverse_blocks' attribute). The matrix representation > of each block > > can then be retrieved using its matrix attribute: > > > sx = ws.covmat_sx.value > matrix = sx.blocks[0].matrix > > Hope this helps! > > > Best, > > > Simon > > > -- > *From:* arts_users.mi-boun...@mailman.rrz.uni-hamburg.de < > arts_users.mi-boun...@mailman.rrz.uni-hamburg.de> on behalf of Rita > Kajtar > *Sent:* Tuesday, November 26, 2019 8:17:05 PM > *To:* arts_users...@mailman.rrz.uni-hamburg.de > *Subject:* [arts-users] atm.scenario & cov-mat issues > > Hello! > > I have a few questions, the first ones related to the issues I encounter > when I try to use a subarctic atmospheric scenario with user-defined > pressure and retrieval pressure grids (*), and the next questions related > to what precisely does the covariance matrix that my ARTS file produces > contain and how can one actually extract certain blocks out of it once one > knows what it contains; the documentation on covmat_sx does not provide too > much information on this (**) > > (*) > ### > - I am running an adapted version on TestOEM.arts and while the pressure > grid and the pressure retrieval grid I set work well with the tropical atm. > background that TestOEM.arts comes with, I get the following error when I > try to use a subarctic-winter scenario: > > Run-time error in method: AtmFieldsCalc > There is a problem with the grids for the following interpolation: > Raw field to p_grid > The minimum of the new grid must be inside the original grid. > (We allow a bit of extrapolation, but not so much). > Minimum of original grid: -2.3969 (0.091) > Minimum allowed value for new grid: -2.7956 (0.0610782) > Actual minimum of new grid: -2.81347 (0.0599964) > > - If I then replace the pressure grid with a 'shorter' one, so that I make > sure I fall within the minimum allowed value of the grid, I hit an assertion: > > > - xaStandard > Assertion failed: (og_min <= tng), function gridpos, file > /Users/mypath/arts/src/interpolation.cc, line 345. > Abort trap: 6 > > (**) > ## > - Why for a simulation containing three retrieval species. i.e. O3, > freq.shift and polyfit (no winds considered this time), the retrieval > covariance matrix (Sx) contains six retrieval errors? and what are those > representing? The terminal output shows a 17 x 17 sized covariance matrix, > which corresponds to the 15 elem O3 array + 1 elem of freq-shift + 1 elem > of polyfit. > (covmat_sx attached) > > - I can import the generated covariance matrix in my Python code, but how > can I extract the different
Re: [arts-users] jacobianDOIT status and scat_meta_data doubt
> Victoria > > ___ > arts_users.mi mailing list > arts_users.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi > -- = Jana Mendrok, Ph.D. Deutscher Wetterdienst Frankfurter Str. 135 63067 Offenbach am Main, Germany Email: jana.mend...@dwd.de Phone : +49 (0)69 8062 3139 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] Extract element from vector
Hi Hugh (&all)! Jana is correct: I could probably do this without using the batch agenda; I > do not think I am doing anything which fundamentally prevents this. But I > could not work out how to do that either 🙁 . I will probably try to sort > that out at some point. > It's actually very simple: (but I had to look it up in an example controlfile, too. I keep forgetting things. And usually copy from older setups or examples.) MatrixSet( sensor_los, [ 180; 170; 160; 150; 140; 130] ) Meanwhile, Oliver's hints have enabled me to get it working by using the > batch agenda. > Always good to learn something new. And to have alternatives! :) Best wishes, Jana -- ========= Jana Mendrok, Ph.D. Deutscher Wetterdienst Frankfurter Str. 135 63067 Offenbach am Main, Germany Email: jana.mend...@dwd.de Phone : +49 (0)69 8062 3139 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] Extract element from vector
Hi Hugh,
you are probably doing things in the batch agenda, that make you require or
prefer a batch agenda. But if it's just about multiple LOS - they can also
be done in a single, non-batch run (that's why sensor_los is a matrix; one
of it's dimensions is the number of LOS, or in a more general way the
"number of measurement blocks" as the doc calls it).
Best wishes,
Jana
On Thu, Jul 18, 2019 at 9:46 AM PUMPHREY Hugh
wrote:
> Dear ARTS gurus,
>
> I am trying to use ARTS's batch feature to do calculations for a range of
> values of sensor_los.
>
> The relevant bit of my control file goes:
>
> VectorCreate(my_loses)
> VectorSet(my_loses, [180,170,160,150,140,130])
> Print(my_loses)
> IndexSet(ybatch_n,7)
>
> AgendaSet(ybatch_calc_agenda){
> Extract(sensor_los,my_loses,ybatch_index)
> Print( ybatch_index, 0 )
> Print( sensor_los, 0 )
>## Actual calculations including iyCalc go here
> }
>
> But I get an error in the Extract() method which says:
>
> Workspace variable belongs to the wrong group: my_loses is not
> ArrayOfMatrix, it is Vector
>
> At the root of this is that sensor_los is a matrix, even though it has
> only one element. I have tried a few other combinations of creating a
> matrix instead of a vector and/or using Select() instead of Extract() to
> extract a value from it. Select() was no good because ybatch_index is an
> index, not an array of index.
>
> What am I doing wrong? How do I create a 1-D array of numbers which
> Extract() will extract a single value from? I am sure I am being really dim
> here :-(
>
> Best wishes
>
> Hugh Pumphrey
>
>
>
> The University of Edinburgh is a charitable body, registered in Scotland,
> with registration number SC005336.
> ___
> arts_users.mi mailing list
> arts_users.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
>
--
=
Jana Mendrok, Ph.D.
Deutscher Wetterdienst
Frankfurter Str. 135
63067 Offenbach am Main, Germany
Email: jana.mend...@dwd.de
Phone : +49 (0)69 8062 3139
=
___
arts_users.mi mailing list
arts_users.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
[arts-users] MDPI Atmosphere Special Issue "Radiative Transfer Models of Atmospheric and Cloud Properties"
Hi, Franz (Schreier) hinted me at MDPI Atmosphere journal currently having a special issue on "Radiative Transfer Models of Atmospheric and Cloud Properties", open for submission till the end of the year. Maybe of interest for upcoming ARTS (related) publications? https://www.mdpi.com/journal/atmosphere/special_issues/radiative_transfer_models Wishes, Jana -- = Jana Mendrok, Ph.D. (Geoscience) Email: jana.mend...@gmail.com Phone : +46 (0)708 860 729 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] Absorption vector for ARTS
get through. And if then the results look OK. > > Jana: Do you have time to elaborate? Karina works with oriented particles. > > Bye, > > Patrick > > > > > virga|~: arts -d scat_dataCheck > > *---* > Workspace method = scat_dataCheck > - > > Furthermore, by default it is checked that *scat_data* does not > contain any invalid values and that the scattering matrix is > properly normalized. Proper normalization is defined by the maximum > allowed albedo deviation *sca_mat_threshold* (for details see > *scat_dataCheck*). > Method for checking the validity and consistency of the single > scattering properties in *scat_data*. > > This function checks that *scat_data* does not contain any NaN and > that the 'scalar' properties K11, Z11, and a1 are non-negative. > > When *check_type* is 'all', this function checks that the solid > sphere integrated scattering matrix (int_Z11), which is supposed to > be normalized to the scattering cross section, is sufficiently > consistent with the scattering cross section (C_sca) derived from > the difference of extinction (K11) and absorption (a1): > int_z11 ~ C_sca = K11-a1. > The check is skipped if *check_type* is 'sane'. > > Sufficient consistency is defined by the maximum allowed deviation > in single scattering albedo, *sca_mat_threshold*, testing for >( /-1. ) * ( / ) <= sca_mat_threshold. > > > Synopsis: > > scat_dataCheck( scat_data, check_type, > sca_mat_threshold ) > > > Authors: Claudia Emde, Jana Mendrok > > > Variables: > > INscat_data (ArrayOfArrayOfSingleScatteringData): >Array of single scattering data. > GIN check_type (String, Default: "all"): >The level of checks to apply on scat_data (see above). > GIN sca_mat_threshold (Numeric, Default: 5e-2): >Threshold for allowed albedo deviation (see above). > > *---* > > > > > > On 2019-04-08 13:47, Karina McCusker wrote: > > Hi Patrick, > > > > Hope you are keeping well! > > > > > > I have been concentrating on other topics of my PhD but am now back to > > looking at ARTS. You may remember that I wanted to input my own > > scattering calculations. I thought I had implemented them correctly > > after testing with the spheroidal case. However, for a large number of > > the particles I’m now using, I am running into one of 2 problems - > > either the absorption vector is negative, or it is not negative but when > > I try to run ARTS I get an error along the lines of: > > > > Run-time error in controlfile: cfile_passive.arts > > > > Run-time error in method: scat_data_checkedCalc > > > > Deviations in scat_data too large: > > > > scat dev [%] 94.3242 at nominal (actual) albedo of 0.127368 (0.247507). > > > > Check entry for scattering element 0 of scattering species 0 at 0. > > frequency, 0. temperature, and 0. incident polar angle! > > > > Therefore, I believe I am not calculating the absorption vector > > correctly. I was wondering if it is possible for ARTS to do the > > absorption vector calculation, or if this must be included as input? > > > > Many thanks for your help, > > > > Karina > > > > > > > > > > Karina McCusker > > > > -PhD Student > > > > /Fast, approximate methods for electromagnetic wave scattering by > > complex ice crystals and snowflakes./ > > > > / > > / > > > > Room 505, Philip Lyle Building > > > > Department of Meteorology > > > > University of Reading > > > > > > > -- = Jana Mendrok, Ph.D. (Geoscience) Email: jana.mend...@gmail.com Phone : +46 (0)708 860 729 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] O3 Jacobians
Thanks, Patrick! On Fri, Apr 5, 2019 at 2:14 PM Patrick Eriksson < patrick.eriks...@chalmers.se> wrote: > Hi, > > > > so, logrel and rel only make a difference in a (externally coupled) > > retrieval, e.g. with qpack, not with plain ARTS. is that correct? > > Yes. > > > > > so, when I'd like to label a (logrel) O3 Jacobians plot, I could use K / > > 100% O3? or what would you suggest? > > Yes, that labeling looks OK, besides that the value of the Jacobian also > depends on the layer thickness. The original values are per layer. One > option is to divide the Jacobian with the layer thickness in km to write > e.g. "K/(100%O3*km)" > > /P > -- = Jana Mendrok, Ph.D. (Geoscience) Email: jana.mend...@gmail.com Phone : +46 (0)708 860 729 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] O3 Jacobians
Hi Patrick, Hi all, On Fri, Apr 5, 2019 at 6:16 AM Patrick Eriksson < patrick.eriks...@chalmers.se> wrote: > > Are you just interested in the Jacobian or will you also perform > retrievals (by Qpack?)? > for now, just in the Jacobians. though, the setup for the O3 Jacobians as we used so far comes from Uwe's O3 retrieval processing. I start thinking that the logrel setting is probably not the best when trying to understand the meaning and the role of Jacobians, and when comparing the O3 Jacobians, e.g. to the wind Jacobians (@Mathias, @Rita, we should probably discuss this...). later this shall result in retrievals (of wind, actually), likely using qpack (for the simple reason that we use Uwe's O3 retrieval as example/proxy/base and this is using qpack). > > > our main issue here is to understand what unit logrel(O3) implies. > > following Patrick's advice from the previous (wind) thread, I checked > > the AUG (and the correct one for that matter - cause we're still using > > arts2.2; 'logrel' retrieval unit seems to be gone in arts2.3) - et voila! > > (it's sec. 16.4 for all others interested in the matter) > > > > so, according to my understanding of Sec16.4, 'logrel' is (at least > > regarding the Jacobian output) identical to 'rel', which in turn for the > > (semi-)analytical jacobians corresponds (or, is scaled) to a 100% change > > in the abs species (here, O3) with respect to the species' VMRs (as > > given by the vmr_field interpolated to the species' Jacobian p_grid). Is > > that understanding correct? > > I would say yes. In my words: If we denote "logrel" as z, then > z=log(x/xa). That is you retrieve the log of ratio with respect to a > priori. > > logrel and rel give identical results for the first iteration of a > retrieval. But differ for later iterations (handled by Qpack). > so, logrel and rel only make a difference in a (externally coupled) retrieval, e.g. with qpack, not with plain ARTS. is that correct? so, when I'd like to label a (logrel) O3 Jacobians plot, I could use K / 100% O3? or what would you suggest? (well, just for this sake it's probably more straight-forward to use 'vmr' units and label them K/1 or rescale them to K/ppm...) > > > and how is that for 'vmr' then? would the jacobians correspond to a '1' > > (or 10^6 ppm) change in the species? or a 1ppm change? (i'm unsure what > > VMR's SI unit is...). > > All Jacobians are for a unit change, so here it is "1!. That is, what > change would you get if you add a full atmosphere of the gas of concern. > Ok, thanks for the confirmation! Best wishes, Jana -- = Jana Mendrok, Ph.D. (Geoscience) Email: jana.mend...@gmail.com Phone : +46 (0)708 860 729 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] O3 Jacobians
Hi, On Thu, Apr 4, 2019 at 12:35 PM Richard Larsson wrote: > [...] > In your jacobianAddAbsSpecies, you set the unit of x to be logrel. So, the > unit in your case of J will be [iy_unit / logrel(O3)]. > our main issue here is to understand what unit logrel(O3) implies. following Patrick's advice from the previous (wind) thread, I checked the AUG (and the correct one for that matter - cause we're still using arts2.2; 'logrel' retrieval unit seems to be gone in arts2.3) - et voila! (it's sec. 16.4 for all others interested in the matter) so, according to my understanding of Sec16.4, 'logrel' is (at least regarding the Jacobian output) identical to 'rel', which in turn for the (semi-)analytical jacobians corresponds (or, is scaled) to a 100% change in the abs species (here, O3) with respect to the species' VMRs (as given by the vmr_field interpolated to the species' Jacobian p_grid). Is that understanding correct? and how is that for 'vmr' then? would the jacobians correspond to a '1' (or 10^6 ppm) change in the species? or a 1ppm change? (i'm unsure what VMR's SI unit is...). best wishes, Jana -- = Jana Mendrok, Ph.D. (Geoscience) Email: jana.mend...@gmail.com Phone : +46 (0)708 860 729 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] Wind calculations (resent)
Hi, On Wed, Apr 3, 2019 at 4:30 PM Richard Larsson wrote: > [...] > Indeed, the description seems coherent but difficult to follow. Can you > point out where in the docs you found this? It should be updated to > clearly read that a positive wind_v in 1D equates to a positive v in the > standard (1 - v/c) Doppler shift expression. > I took my info from the built-in doc for wind_v_fields and sensor_los. I did now update the wind field section in the AUG with an explicit statement that positive/negative v-winds in 1D correspond to tail/head winds, respectively (incl a reference to the AUG section Patrick pointed out). On Wed, Apr 3, 2019 at 6:40 PM Patrick Eriksson < patrick.eriks...@chalmers.se> wrote: > The definition of the winds do not change between 1D, 2D and 3D. That > would at least lead to messy code. > I'm aware of this. And no critisism of that at all. > > This is in fact a question of the azimuth angle of the sensor. There is > also a north direction in 1D and the sensor is assumed to be looking > exactly North for 1D. This is explained in Sec 3.2 of AUG: > > 1D ... The sensor is assumed to by directed towards the North pole, > corresponding to an azimuth angle of 0 ◦. > > Maybe few are looking in AUG so I just also added this information to > the built-in doc of sensor_los. > I had indeed not checked the AUG, but used the built-in doc instead. Thanks for adding the clarification there, Patrick! However, the tricky part here (and on other occassions), particularly for people not that familiar with ARTS, is to know what to look for and where look for it specifically: for the 1D wind case, even with Patrick's clarification, the crucial point is/was join the information available in the wind_v_fields and the sensor_los/atm_dim documentation. I am not sure, if I had taken a look into the AUG regarding that matter that this would have included the atm dim (3.2) section. But, that's why the mailinglist is so great! there are people out there with better overview and better detail knowledge, who can answer questions or at least point one in a (better) direction where to look for. :) So thanks, Patrick & Richard (and everyone else contributing on other occassions) for your valuable feedback! Best wishes, Jana -- = Jana Mendrok, Ph.D. (Geoscience) Email: jana.mend...@gmail.com Phone : +46 (0)708 860 729 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] Wind calculations (resent)
Hi, thanks Richard for your feedback. I'm not sure, though, whether I really understand it (incl. wondering why you talk about jacobians here...). *scratches head* we're trying to pin down where the wind is blowing in a 1D atm setup. 1D allows us to have vertical (w) and horizontal (v) winds that affect the signal. let's forget about the vertical, that one is clear. for the horizontal, there is two possible wind directions in a 1D case - a head wind (aka blowing in the observer's face) and a tail wind (aka blowing from the observer's back). which of these corresponds to a positive, which to a negative wind(_v) speed. starting from your "For the 'absolute' wind speed option, a positive retrieved sign is equivalent to a red-shift" and equating a red-shift with observer moving away from source (or source from observer...), a positive wind should mean a tail wind. which actually seems indeed in agreement with info I dig from the ARTS documentation (not that easy to find and combine for a beginner...): wind_v doc says positive v-winds are winds blowing south to north (which alone isn't very helpful for 1D setups - there is no north in 1D...); sensor_los doc says for the 2D case (allowing positive and negative zenith angles - in order to distinguish two possible viewing directions) that positive angles are equivalent to viewing towards higher latitudes, ie towards north. assuming this is valid for 1D, too (ie in 1D the observer always looks towards north) means for the 1D case positive winds (blowing to north) equate tail winds (for an observer looking north), negative winds are head winds. to confirm this, Rita, you could have a look where the line peak moves (prefereably in a high-spectral resolution simulation) for positive and negative winds, respectively. for positive it should move to lower freqs, for negative to higher. best wishes, Jana On Wed, Apr 3, 2019 at 12:03 PM Richard Larsson wrote: > Hi Rita, > > For the directional components, the sign of a retrieved component with the > ARTS Jacobian is positive along the axes themselves. The direction the > sensor is looking only influences the scale of the Jacobian, not the sign > of the direction of the retrieval calculation. If you look parallel or > anti-parallel to the field, the values inside the Jacobian switch signs > accordingly to work on the external field. As an example, you should be > able to make measurements at several different directions and, if you > assume the field is uniform, retrieve just one field without any > transformation on the components themselves inside the calculations. > > For the 'absolute' wind speed option, a positive retrieved sign is > equivalent to a red-shift, or a Doppler shift below unity if you wish. > This is much messier to work with during ARTS iterations, so make sure your > signal is easy to interpret if you use it. This is of course closer to the > physics of what is going on with the signal itself, since all we really can > see of the wind is how much it is blue- or red-shifting the signal. > > With hope, > //Richard > > Ps. Oliver, please sent another email when it is fixed. > > > > Den ons 3 apr. 2019 kl 13:36 skrev Oliver Lemke < > oliver.le...@uni-hamburg.de>: > >> Hi all, >> >> Sorry if you received the mail below already. We're currently >> investigating a mail delivery problem to Gmail adresses. If you've already >> received the mail from Rita yesterday please disregard this mail. >> >> Cheers, >> Oliver >> >> >> > From: Rita Edit Kajtar >> > Subject: Wind calculations >> > Date: 2 April 2019 at 10:36:54 CEST >> > To: "arts_users.mi@lists.uni-hamburg.de" < >> arts_users.mi@lists.uni-hamburg.de> >> > >> > >> > Hello! >> > >> > >> > I have a short question regarding wind calculations. >> > >> > What is the general convention assumed for determining the sign of the >> wind speeds having the measuring instrument as the reference point? Are the >> winds blowing towards the instrument considered positive and those blowing >> away from the instrument negative or the other way around? >> > >> > The ARTS documentation provides information for how the sign should be >> considered regarding the four cardinal directions, but not relative to a >> measuring device. >> > >> > >> > Best regards, >> > Rita Kajtar >> >> >> ___ >> arts_users.mi mailing list >> arts_users.mi@lists.uni-hamburg.de >> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi >> > _
Re: [arts-users] Including clouds from the Chevallier_91L datasets to radio link simulation
t to simulate the
> attenuation due to gases, different types of clouds (ice and water) and
> rain/snow. The frequency range that I am interested is roughly from 90 GHz
> to 275 GHz.
>
> I actually switched already to the latest development version and was able
> to run my simulation on Monday without any errors. What I did was that I
> interpolated the chevalier data to the simulation grid that I am using as
> follows:
>
> GriddedField3Create( chevallier_data )
> ReadXML( chevallier_data, "Chevallier_91L/cirrus/Chevallier91L.cirrus.CIW.xml"
> )
> GriddedFieldPRegrid( chevallier_data, p_grid, chevallier_data, 1, 1 )
> GriddedFieldLatLonExpand( chevallier_data, chevallier_data )
> GriddedFieldLatLonRegrid( chevallier_data, my_lat_grid, my_lon_grid,
> chevallier_data, 1 )
> WriteXML("ascii", chevallier_data, "interpolated.xml" )
>
> Then I converted the interpolated data to a tensor4 using a python script.
> I also had to modify the density fields so that they are zeros outside and
> at the edges of the cloud box. This was very cumbersome and I was left
> wondering if there was a simpler way to do it.
>
> Then I was able to import the mass density fields in the simulation using
> the available workspace variables and run the simulation with some minor
> modifications and adding these commands:
>
> cloudboxSetFullAtm
> pnd_fieldCalcFromscat_speciesFields
>
> Two important notes that I could not find in the user manual or
> online documentation:
> - The maximum size of the cloud box in latitude and longitude grids is 20
> degrees of the edges of the simulation grid
> - The density fields must cover the whole latitude/longitude area of the
> simulation grid
>
> Now I am trying to figure out if the results I am getting are reasonable
> or not.
>
> I am just starting to learn microwave propagation in the atmosphere,
> and this tool seems like a good way to help me do it. I appreciate making
> this project open source.
>
> Regards,
> Sampo
>
>
> 2017-11-02 6:39 GMT+01:00 Patrick Eriksson :
>
>> Dear Sampo Salo,
>>
>> I will not give you an answer here, just asking some questions.
>>
>> Can you write a few words about what you want to simulate, more exactly?
>> Is it link budget for a ground-station? What frequency range? Easier to
>> provide help knowing this.
>>
>> What ARTS version are you using? If you are using v2.2, would it be an
>> option to switch to latest development version?
>>
>> "Clouds" means clouds consisting of liquid droplets (ie matching LWC)?
>>
>> Regards,
>>
>> Patrick
>>
>>
>>
>>
>> On 2017-10-26 11:07, Sampo Salo wrote:
>>
>>> Hi all,
>>>
>>> I have a slightly modified version of the link budget simulation
>>> "DemoLinkBudget" provided in the "planetary toolbox". I want to add clouds
>>> and rain to this simulation using the Chevallier_91L datasets that I can
>>> find in the "control files".
>>>
>>> I _think_ what I would like to do is as follows:
>>>
>>> 1. I want to generate particle number density fields from the
>>> Chevallier_91L data which is in plain mass densities (kg/m3 for clouds and
>>> kg/m2/s for rain) in a corresponding pressure grid.
>>>
>>> 2. Then I want to interpolate/add these pnd fields in a cloud box that
>>> corresponds to the pressure grid that I already have generated in my
>>> existing simulation.
>>>
>>> Could anyone here help me to find the correct way to add clouds in my
>>> simulation? I have been thinking and thinking about this but I can't find
>>> the way to do this.
>>>
>>> Regards,
>>> Sampo
>>>
>>>
>>> ___
>>> arts_users.mi mailing list
>>> arts_users.mi@lists.uni-hamburg.de
>>> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
>>>
>>>
>
> ___
> arts_users.mi mailing list
> arts_users.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
>
>
--
=
Jana Mendrok, Ph.D. (Researcher)
Chalmers University of Technology
Department of Space, Earth and Environment
SE-412 96 Gothenburg, Sweden
Email: jana.mend...@chalmers.se
Phone : +46 (0)31 772 1883
=
___
arts_users.mi mailing list
arts_users.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] 22 GHz optical depth
Hi Gabriele,
what ARTS version are you using?
generally, you should use the same (major, ie 2.0, 2.2 or so) ARTS and
atmlab versions. having said that, did we have proper y_aux support in
ARTS2.0 already (ie the pre-planet toolbox version), Patrick?
wishes,
Jana
On Mon, Feb 20, 2017 at 11:55 AM, Gabriele Mevi
wrote:
> Dear Patrick
> Thank you for your answer.
> I tried to use your settings, however the y_aux contains again the same
> values (about 0.97). Maybe I'm not using the latest version of the program
> because your second command line is not recognized by qcheck so I ran the
> code without it.
>
> I'm using the emission agenda because I'm primary interested in the
> simulated spectrum and in the Jacobian calculation.
> I'm pretty sure that I'm simulating the zenital emission. I show you other
> lines of my code.
>
> Q.CLOUDBOX_DO = false;
> Q.YCALC_WSMS = { 'yCalc' };
> Q.PPATH_LMAX = 1000;
> Q.PPATH_STEP_AGENDA = { 'ppath_stepGeometric' };
> Q.Y_UNIT = 'RJBT';
>
> Q.SENSOR_LOS =0;
> Q.SENSOR_POS = Q.R_GEOID + Q.Z_SURFACE;
> Q.IY_SPACE_AGENDA = { 'Ignore(rte_los)', 'Ignore(rte_pos)', ...
> 'nelemGet(nrows,f_grid)', ...
> 'Copy(ncols,stokes_dim)', ...
> 'MatrixSetConstant(iy,nrows,ncols,0)' };
> Q.SENSOR_DO = false;
>
> Q.ANTENNA_DIM = 1;
> Q.MBLOCK_ZA_GRID = 0;
>
> If you have any suggestions please let me know.
> Thank you for your help.
>
> ___
> arts_users.mi mailing list
> arts_users.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
>
>
--
=
Jana Mendrok, Ph.D. (Researcher)
Chalmers University of Technology
Earth and Space Sciences
SE-412 96 Gothenburg, Sweden
Email: jana.mend...@chalmers.se
Phone : +46 (0)31 772 1883
=
___
arts_users.mi mailing list
arts_users.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] Wikipedia List on RT models
what about the ESAS light study, specifically the RT tools review report (WP1100)? available from the project website ( http://esaslight.libradtran.org/internal/Wiki/doku.php?id=task1). on esa's archive, unfortunately only the executive summary is available ( https://gsp.esa.int/gsp-study-view/-/wcl/gaUaMHco1QJ9/10192/towards-a-generic-radiative-transfer-model-for-the-earth-surface-atmosphere-system-esas-light), which doesn't mention ARTS. wishes, Jana On Thu, Nov 3, 2016 at 3:39 PM, Stefan Buehler < stefan.bueh...@uni-hamburg.de> wrote: > Hi Gerrit, > > a great initiative! > > Comments: > > When I tried searching for “arts” on wikipedia, however, it does not show > up. Is there anything special that needs to be done for it to also be > searchable by name? > > > Can anyone recommend (other) independent, secondary, third-party > > sources that describe ARTS /and/ can attest that ARTS is relevant to > > the field? > > How strict does independent have to be? This article mentions ARTS as a > reference model for radiation fluxes: > > Pincus, R., E. J. Mlawer, L. Oreopoulos, A. S. Ackerman, S. Baek, M. > Brath, S. A. Buehler, K. E. Cady-Pereira, J. N. S. Cole, J.-L. Dufresne, M. > Kelley, J. Li, J. Manners, D. J. Paynter, R. Roehrig, M. Sekiguchi, and D. > M. Schwarzkopf (2015), Radiative flux and forcing parameterization error in > aerosol-free clear skies, Geophys. Res. Lett., 42(13), 5485–5492, > doi:10.1002/2015GL064291. > > But I’m one of the co-authors, so perhaps it is not independent enough. > > I think among the research papers that cite our ARTS paper, there are many > that are completely independent of us, but use ARTS as a forward model. > Could you not write something like: > > “ARTS has been used by many researchers outside the core developer team > for their projects in radiative transfer and remote sensing.” Then add a > list of those papers that used ARTS, but have no co-author from us. > > Best wishes, > > Stefan > ___ > arts_users.mi mailing list > arts_users.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi > -- = Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Email: jana.mend...@chalmers.se Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] Questions on frequency grid
Hi Emma, generally ARTS uses a monochromatic frequency grid (aka there are no bins), defined by the f_grid. In my understanding (stefan or someone more deeply involved with the gas aborption modules might correct me...), all the spectral lines are then sampled on this exact grid. That is, if your f_grid happens to be too coarse and the line peaks will happen to be between the grid points, you will simple not sample them. (effect of different freq sampling methods for OLR calculations using ARTS had been analysed in http://www.sat.ltu.se/publications/all.php?bibonly=buehler06:_olr_modeling_jqsrt ) there's a bit more of sophistication in sensor descriptions/instrument functions. for channels you define corresponding f_grid and (instrumental) weighting functions, with which the f_grid is convolved. (more on the concept in http://www.sat.ltu.se/publications/all.php?bibonly=eriksson06:_sensor_ijrs) there's a couple of ways to do this (and i'm not very familiar with). depending on what type of instrument you're after, you can have a look into controlfiles/instruments/ for examples (there's a couple of MW radiometers defined. as well as HIRS and AVHRR.). then there's *ySimpleSpectrometer* for simple box-car spectral functions. hope that helps a bit... best wishes, Jana On Fri, Sep 9, 2016 at 5:16 PM, Turner, Emma wrote: > Dear arts mailing list, > > > > I’ve been digging into the documentation to try and find out about the > internal frequency calculation grid but I can’t seem to find the answer to > my query so I asking you directly. > > > > I am using the forward qarts model to simulate clearsky down-welling > brightness temperatures on a regular 0.5 GHz grid. On what frequency > increments are the line absorption calculations performed within each 0.5 > GHz region? As I am using ‘on the fly’ line absorption am I right in > thinking there is no internal calculation grid but that the absorption > co-efficients are calculated for each spectral line within the bin and > summed? What happens to the edges of the line shapes, particularly when > they extend beyond the edge of a frequency grid point? Are they carried > over to the next bin? Also what happens when a spectral line falls exactly > on a 0.5 GHz frequency? Is the absorption split equally between the two > neighbouring regions? > > > > Many thanks in advance, > > Emma > > > > -- > > Dr. Emma Turner > > Radiative Transfer Scientist > > Clouds and Radiation Group > > Atmospheric Processes and Parameterizations > > *Met Office* | Fitzroy Road | Exeter | EX1 3PB > > Desk: C2-069 Tel: +44 (0)1392 884328 Email: emma.tur...@metoffice.gov.uk > > *www.metoffice.gov.uk/research/people/emma-turner > <http://www.metoffice.gov.uk/research/people/emma-turner>* > > > > > > ___ > arts_users.mi mailing list > arts_users.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi > > -- = Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] error in disort example
and just seeing this... shouldn't lead to a built error, but later on when running checks: with arts2.3 you also want to use the corresponding version of arts-xml-data, i.e. arts-xml-data2.3. good luck! Jana On Thu, Sep 1, 2016 at 2:43 PM, Jana Mendrok wrote: > Hi Elisa, > > please generally post questions to the user mailinglist, not to > individuals. > > I don't have an answer to your build question. but someone on the list > might have and pick up the case ... (Oliver should know). > > wishes, > Jana > > On Thu, Sep 1, 2016 at 12:36 PM, Elisa Castelli > wrote: > >> Hi Jana, >> >> I've downloaded the arts2.3 version from http://www.radiativetransfer.o >> rg/misc/download/trunk/ >> howver I've some problems with the installation: >> all seems ok with the cmake: >> >> -- C++11 support detected. >> -- A library with BLAS API found. >> -- A library with BLAS API found. >> -- A library with LAPACK API found. >> -- Found arts-xml-data in /home/elisa/ARTS/arts-xml-data-2.2.1 >> -- Disort enabled (use -DNO_DISORT=1 to disable) >> -- FASTEM enabled (use -DNO_FASTEM=1 to disable) >> -- Refice enabled (use -DNO_REFICE=1 to disable) >> -- Tmatrix enabled (use -DNO_TMATRIX=1 to disable) >> -- Configuring done >> -- Generating done >> -- Build files have been written to: /home/elisa/ARTS/arts/build >> >> however when compiling with make i get this error >> >> [ 0%] Built target UpdateAutoVersion >> [ 2%] Built target disort >> [ 2%] Built target test_disort >> [ 3%] Built target fastem >> [ 3%] Built target refice >> [ 4%] Built target tmatrix >> [ 5%] Built target tmatrix_ampld >> [ 6%] Built target tmatrix_tmd >> [ 8%] Built target microhttpd >> [ 8%] Built target auto_version_h >> [ 10%] Built target methods >> [ 15%] Built target matpack >> Linking CXX executable make_auto_workspace_h >> src/CMakeFiles/make_auto_workspace_h.dir/build.make:191: recipe for >> target 'src/make_auto_workspace_h' failed >> CMakeFiles/Makefile2:917: recipe for target >> 'src/CMakeFiles/make_auto_workspace_h.dir/all' >> failed >> Makefile:127: recipe for target 'all' failed >> >> collect2: error: ld returned 1 exit status >> src/CMakeFiles/make_auto_workspace_h.dir/build.make:191: recipe for >> target 'src/make_auto_workspace_h' failed >> make[2]: *** [src/make_auto_workspace_h] Error 1 >> CMakeFiles/Makefile2:917: recipe for target >> 'src/CMakeFiles/make_auto_workspace_h.dir/all' >> failed >> make[1]: *** [src/CMakeFiles/make_auto_workspace_h.dir/all] Error 2 >> Makefile:127: recipe for target 'all' failed >> make: *** [all] Error 2 >> >> It seem that something goes wrong when compiling matpack do you have any >> idea on how can I solve this? >> >> Thank you again >> best wishes, >> >> Elisa >> >> > > > -- > = > Jana Mendrok, Ph.D. (Project Assistent) > Chalmers University of Technology > Earth and Space Sciences > SE-412 96 Gothenburg, Sweden > > Phone : +46 (0)31 772 1883 > = > -- = Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] error in disort example
Hi Elisa, please generally post questions to the user mailinglist, not to individuals. I don't have an answer to your build question. but someone on the list might have and pick up the case ... (Oliver should know). wishes, Jana On Thu, Sep 1, 2016 at 12:36 PM, Elisa Castelli wrote: > Hi Jana, > > I've downloaded the arts2.3 version from http://www.radiativetransfer.o > rg/misc/download/trunk/ > howver I've some problems with the installation: > all seems ok with the cmake: > > -- C++11 support detected. > -- A library with BLAS API found. > -- A library with BLAS API found. > -- A library with LAPACK API found. > -- Found arts-xml-data in /home/elisa/ARTS/arts-xml-data-2.2.1 > -- Disort enabled (use -DNO_DISORT=1 to disable) > -- FASTEM enabled (use -DNO_FASTEM=1 to disable) > -- Refice enabled (use -DNO_REFICE=1 to disable) > -- Tmatrix enabled (use -DNO_TMATRIX=1 to disable) > -- Configuring done > -- Generating done > -- Build files have been written to: /home/elisa/ARTS/arts/build > > however when compiling with make i get this error > > [ 0%] Built target UpdateAutoVersion > [ 2%] Built target disort > [ 2%] Built target test_disort > [ 3%] Built target fastem > [ 3%] Built target refice > [ 4%] Built target tmatrix > [ 5%] Built target tmatrix_ampld > [ 6%] Built target tmatrix_tmd > [ 8%] Built target microhttpd > [ 8%] Built target auto_version_h > [ 10%] Built target methods > [ 15%] Built target matpack > Linking CXX executable make_auto_workspace_h > src/CMakeFiles/make_auto_workspace_h.dir/build.make:191: recipe for > target 'src/make_auto_workspace_h' failed > CMakeFiles/Makefile2:917: recipe for target > 'src/CMakeFiles/make_auto_workspace_h.dir/all' > failed > Makefile:127: recipe for target 'all' failed > > collect2: error: ld returned 1 exit status > src/CMakeFiles/make_auto_workspace_h.dir/build.make:191: recipe for > target 'src/make_auto_workspace_h' failed > make[2]: *** [src/make_auto_workspace_h] Error 1 > CMakeFiles/Makefile2:917: recipe for target > 'src/CMakeFiles/make_auto_workspace_h.dir/all' > failed > make[1]: *** [src/CMakeFiles/make_auto_workspace_h.dir/all] Error 2 > Makefile:127: recipe for target 'all' failed > make: *** [all] Error 2 > > It seem that something goes wrong when compiling matpack do you have any > idea on how can I solve this? > > Thank you again > best wishes, > > Elisa > > -- = Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] error in disort example
Hi Elisa, thanks for the reporting. and perfectly correct solution that your choose to solve the runtime error problem. (running the test here, i get a runtime error already on the ab_lookup part :O). anyway, please do NOT use the arts2.2 disort, it is buggy. good that you brought that up; we should remove the testcase from the repository. there is a refurbished version in arts2.3. no absolute guarentee that it's bugfree, but tests looked good so far. it has a number of limitations, though. read to online-doc to see, whether it anyway suits your problem. If you want to use Disort, then you need to go to arts2.3 (you will need a number of adaptations in your controlfile, though. or use arts2.3's testcases as starting point). we have tested Disort so far only for downlooking cases. So i can not really say, how good or bad it is for limb simulations. since the default setup returns the plane-parallel radiation field only for the cloudbox, not for the whole atmosphere, and outside the cloudbox ARTS' fully spherical calculation kicks in again, ARTS with Disort interface solution might even be ok for limb cases. Best is, though, if you do some tests comparing ARTS-Disort with a true spherical solution (maybe rather MC than DOIT as we found DOIT to have some issues in case of thick clouds). We're curious to hear about your findings! hope that helps. and thanks again for reporting! best wishes, Jana On Wed, Aug 31, 2016 at 11:22 AM, Elisa Castelli wrote: > Hi, > > when using the example in /arts-2.2.24/controlfiles/artscomponents/disort > (TestDISORT.arts) > I get the following error: > > ERROR: Radiance difference between interpolation > points is too large (factor 3) to > safely interpolate. This might be due to za_grid > being too coarse or the radiance field being a > step-like function. > Happens at boundary 1 between zenith > angels 90 and 100deg for frequency#0, where radiances are 0 and > 4.14453e-15 W/(sr m2 Hz). > > I've solved the problem by changing the za_grid in DoitAngularGridsSet and > now it works. > > I'm trying to simulate limb cloudy spectra and all works well when using > the doit for scattering. > Now I wonder if it is feasible to repeat the same test using disort > instead of doit for scattering. Is that feasible or due to the plane > parallel approximation > only nadir and slant cases can be simulated? > > Thanks, > > Best wishes > > Elisa Castelli > > ___ > arts_users.mi mailing list > arts_users.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi > -- = Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] for help
Hi Shawley, Hi Patrick, hi all, so far I have tested liquid cloud absorption, it works fine (both in arts2.2 and arts2.3): when liquidcloud is in abs_species, AtmRawRead does read the profile (named YOURBASENAME.liquidcloud.xml) and throws an error if no profile is found. xsec_continuum calculates absorption coefficients (you have to have abs_xsec_per_speciesAddConts in your abs_xsec_agenda, though, i assume. which you have if using any of the predefines abs_xsec_agenda's. i didn't check what happens if not.). the issue I found is that there wasn't any check on frequency or temperature validity for the respective models. at temperatures below -40C results are nonsense. i've added checks now in arts2.3. I haven't seen the initial problem description, though. so i don't know what you where actually trying to do, Shawley, and could not reproduce it. to avoid this kind of information loss, ALWAYS send questions to the user mailinglist. NOT to individual people! in case you where trying to use the cloud absorption for IR simulations: while ELL07 permittivity model is claimed to be valid up to 25THz, I'd disencourage use of liquidcloud as an absorption species at IR wavelenghts. this as cloud droplets do scatter significantly in IR (exhibiting IR size parameters around 1), so an absorption-only model can not describe the problem appropriately. arts2.3 is what is called the development version on the ARTS website. download/install instructions available there. best wishes, Jana On Thu, May 26, 2016 at 9:13 AM, Patrick Eriksson < patrick.eriks...@chalmers.se> wrote: > Hi, > > I have provided some small help for Lee, that gets zero absorption for LWC. > > Looking at the controlfile, the problem seems that AtmRawRead is used. The > online doc indicates that the method just handles species, T and Z. Can > anyone confirm? > > If correct, would it be difficult to extend the function to also handle > other "abs_Species" (in a general way)? > > Or can anyone inform Lee about an easy way to get LWC into vmr_field? > > Lee uses v2.2. > > Bye, > > Patrick > > > On 05/26/16 02:50, Lee Shawley wrote: > >> Hi Patrick, >> Thank you for your advice. >> I have checked my LWC profile values, and I am sure it is right. >> However, the problem is still that the liquid cloud absorption is zero. >> I have attached my controlfile and the LWC profile in the attachment. I >> just don’t know how to do with the problem. Maybe you can point out my >> errors. >> Thank you very much! >> Ps. The latest version I can find in the website (radiativetransfer.org) >> is v2.2.55. Where can I get v2.3? >> Best wishes. >> Lee >> >> >> On Wednesday, May 25, 2016 10:30 PM, Patrick Eriksson >> wrote: >> >> >> Hi, >> >> ELL07 is supposed to be better for temperatures below 0C, but I think >> you should be doing fine with liquidcloud-MPM93. >> >> Have you set any LWC values? Please check that vmr_field has non-zeros >> for LWC. >> >> Bye, >> >> Patrick >> > ___ > arts_users.mi mailing list > arts_users.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi > -- = Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] for help
Hi, I assume nothing happend here yet? if so, i'll take a look. but not before end of next week. wishes, Jana ps. it should work through the basic WSM, though. something like (didn't check the exact names of the WSMs): ReadXML GriddedFieldPRegrid (GriddedFieldLatLonRegrid - not needed if everything is 1D) FieldFromGriddedField Append(vmr_field,lwc) Append(abs_species,"liquidcloud-MPM93") i think, i did something like this in the planetary toolbox controlfile examples (but it's probably buried fairly deep in the INCLUDE files). On Thu, May 26, 2016 at 9:13 AM, Patrick Eriksson < patrick.eriks...@chalmers.se> wrote: > Hi, > > I have provided some small help for Lee, that gets zero absorption for LWC. > > Looking at the controlfile, the problem seems that AtmRawRead is used. The > online doc indicates that the method just handles species, T and Z. Can > anyone confirm? > > If correct, would it be difficult to extend the function to also handle > other "abs_Species" (in a general way)? > > Or can anyone inform Lee about an easy way to get LWC into vmr_field? > > Lee uses v2.2. > > Bye, > > Patrick > > > On 05/26/16 02:50, Lee Shawley wrote: > >> Hi Patrick, >> Thank you for your advice. >> I have checked my LWC profile values, and I am sure it is right. >> However, the problem is still that the liquid cloud absorption is zero. >> I have attached my controlfile and the LWC profile in the attachment. I >> just don’t know how to do with the problem. Maybe you can point out my >> errors. >> Thank you very much! >> Ps. The latest version I can find in the website (radiativetransfer.org) >> is v2.2.55. Where can I get v2.3? >> Best wishes. >> Lee >> >> >> On Wednesday, May 25, 2016 10:30 PM, Patrick Eriksson >> wrote: >> >> >> Hi, >> >> ELL07 is supposed to be better for temperatures below 0C, but I think >> you should be doing fine with liquidcloud-MPM93. >> >> Have you set any LWC values? Please check that vmr_field has non-zeros >> for LWC. >> >> Bye, >> >> Patrick >> > ___ > arts_users.mi mailing list > arts_users.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi > -- = Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] Help for CO simulation
hi plj, you mean your signal in general is too small? i think you like to include dry air continuum in your calculations, i.e. include some O2 and N2 absorption models in your abs_species setting. while the line cutoff that you set should be ok for the CO lines themselves, it should be larger for the H2O line(s). the default setup made in general.arts should generally serve your purposes. wishes, Jana On Fri, Mar 18, 2016 at 10:08 AM, plj wrote: > HI all, > I am simulating CO spectrum in 200-400Ghz band. We focus on CO in the > mesosphere, the voigt line shape is good choice for the simulation. > However, the result of voigt line shape is not correct, which is too small. > The attachment is the arts program. What could be wrong? >Thanks, > Best wishes, > PLJ > > > > ___ > arts_users.mi mailing list > arts_users.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi > > -- ========= Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] The use of ARTS in visible
Hi Pengwang, > What could be wrong? I guess it is due to the validity range of PWR98 > model, but wish to get some confirmation from developers/experts. > > If this is due to the validity range of PWR98 model, I consider this as a > bug as continuum model has to be cut at some point, which should be fixed > in the future releases of ARTS. > you're right regarding this being due to validity range of PWR98, which is a microwave model (made for f<300GHz, but ok for f up to 1000GHz; definitely not ok for optical range). we don't consider this a bug, but an issue that is in the responsibility of the user. we expect the user to not blindly apply things, but inform oneself of the meaning (and ensure validity) of the models & data applied. As far as I remember, detailed info about the absorption models is in the user guide (or the theory document, maybe). best wishes, Jana -- ===== Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] scat_data and pnd_field
Hi Patrick, On Wed, Feb 17, 2016 at 4:25 PM, Patrick Eriksson < patrick.eriks...@chalmers.se> wrote: > However, my question deals with pnd_field and scat_data. As usual I set up > everything in Matlab. Before I have used > > ScatElementsPndAndScatAdd > pnd_fieldCalcFrompnd_field_raw > > but now I want to create pnd_field directly. > > Can you just inform me about how the order in scat_data and pnd_field are > related? Not clear as scat_data is an ArrayOfArray. > > Maybe something to add to built-in doc. > order of scatt element entries in pnd_field and in "flattened" scat_data has to be the same order (i.e. first all scat elements of scat species 0, then all scat elem of scat spec 1, etc.). when you prepare pnd_field outside of ARTS it's perfectly ok to have all scat elements in one and the same scat species. i'll have a look to the online doc and try to improve... wishes, Jana -- ===== Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] typo in atmo_venus.arts
Thanks, Elisa! Fixed in arts-2-2-58 and arts-2-3-438. wishes, Jana On Tue, Feb 16, 2016 at 12:52 PM, Oliver Lemke wrote: > Hi Elisa, > > Thanks for the bug report. > > The arts-users mailing has moved to a new server. In the future, please > use the new mailing list address: > > arts_users.mi@lists.uni-hamburg.de > > Cheers, > Oliver > > > > From: Elisa Castelli > > Subject: typo in atmo_venus.arts > > Date: 16 February 2016 at 11:30:05 CET > > To: > > > > > > Hi , > > > > I think there is a typo in : > > > > controlfiles/planetary_toolbox/includes/venus/atmo_venus.arts : > > > > StringSet( atmobase, "planets/Venus/MPS/" ) > > ArrayOfStringSet( atmoarray, > > > ["Venus.spicav.night","Venus.spiva.night_cold","Venus.vira.night", > > "Venus.vira.day","Venus.vira.day_highlat"] ) > > > > "Venus.spiva.night_cold" possibly is ""Venus.spicav.night_cold"" > > > > since I find > arts-xml-data-2.2.1/planets/Venus/MPS/Venus.spicav.night_cold and not > Venus.spiva.night_cold > > > > cheers, > > > > Elisa Castelli > > > ___ > arts_users.mi mailing list > arts_users.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi > -- = Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] calculate absorption coefficients from abs_coefCalc
Hi, I tried different software package for this purpose, and found ARTS is one > of the best in terms of usability. I am not sure what was the motivation > to obsolete abs_coef, which I believe is one of the most important > quantities in radiative transfer. Is there any way to keep it in the > future ARTS development? > essentially, propmat_clearsky_field (where propmat stands for propagation matrix) holds the same information as abs_coef(_per_species) - the diff is that propmat_clearsky is always per species (gets summed up inside ARTS' RT method; you can do the same by yourinterface to your RT solver) and that it allows for vectorized RT, while abs_coef was the scalar abs coefs (0th element of the stokes_dim dimensions will give you the scalar abs coef). that is, propmat_clearsky is the more sophisticated version of abs_coef. we went from abs_coef to propmat_clearsky when introducing Zeeman effect and Faraday rotation - processes that introduce polarization even in case of pure gaseous RT. > If I could find abs_coef_per_species from the current ARTS implementation, > that would be a matrix of [f_grid,p_grid], right? If that is the case, > what is the different between abs_coef and abs_coef_per_species then? I > have read the documentation, and still have no clue on this. > > abs_coef_per_species is an ArrayOfMatrix, where each array element holds the abs coefs matrix (dimension [f_gid,p_grid]) for one species. note that with this variable type, the f_grid and p_grid can theoretically be different for each species. Best wishes, Jana -- ===== Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] calculate absorption coefficients from abs_coefCalc
Hi, what do you intend to do with abs_coeff_user? Do you really process this further within ARTS itself? only then it makes sense to process propmat_clearsky_field into a Tensor3*, i think. Else, I strongly recommend to do any re-shaping / reduction outside of ARTS; other programming languages are much better suited for this kind of task (e.g. you can use the matlab-interface atmlab to have easy access to ARTS output. or the python interface typhon). abs_coef was a Matrix of dimension [f_grid, abs_p] (and abs_coef_per_species an Array holding one abs_coef matrix per defined abs_species). propmat_clearsky_field is a Tensor7 of dimension [species, f_grid, stokes_dim, stokes_dim, p_grid, lat_grid, lon_grid]. That is, for reducing propmat_clearsky_field to what was abs_coef_per_species before would be propmat_clearsky_field[:, :, 0, 0, :, lat_index, lon_index] (in case of 0-indexed varibales; in case of a 1D calculation furthermore lat_index=lon_index=0). As far as I know, that's not possible (at least not easily possible) within ARTS itself. Note that for deriving abs_coef for this, you need to sum up over all species (i.e. over the 0th dimension of propmat_clearsky_field. Best wishes, Jana ps. *by the way, what are the 3 dimensions? neither abs_coeff nor abs_coef_per_species is (or has been for a long time) a Tensor3. That is, you must have post-processed abs_coef(_per_species) anyways? On Mon, Feb 15, 2016 at 6:09 PM, Pengwang Zhai wrote: > Thanks, Jana. Too bad that the only arts feature that I am using is now > obsolete. > > Now given propmat_clearsky_field, can I somehow obtain abs_coeff from it? > > I used the following commands to create abs_coeff_user, which is the > absorption coefficients per specie, > > Tensor3Create(abs_coeff_user) > Reduce(abs_coeff_user,propmat_clearsky_field) > > can I add the coefficients per specie abs_coeff_user together to create > abs_coeff within arts? > > I could do this with other tools but wish to know how to do in arts, which > is more convenient. > > Thanks, > > Pengwang > > > > On Feb 15, 2016, at 12:00 PM, Jana Mendrok > wrote: > > > > Dear Pengwang, > > > > please take a look at the workspace variable propmat_clearsky_field (and > the workspace method propmat_clearsky_fieldCalc, that calculates this > variables). Could they probably provide the output you need? > > > > abs_coef and its *Calc method are obsolete and not supported anymore. > > > > Best wishes, > > Jana > > > > > > On Mon, Feb 15, 2016 at 4:30 PM, Pengwang Zhai wrote: > > Hi, > > > > I used earlier version of ARTS to calculate the total absorption > coefficients with: > > > > abs_coefCalc > > > > and found it is very useful. Now with the new version, this does not > work any more. After reading the change log I found that it is replaced with > > > > abs_coefCalcFromXsec > > > > However, after numerous attemps I could not make this method working for > me. Would you please provide a template arts file on the usage of this > method? > > > > Thanks very much and hope all the best, > > > > Yours > > > > _______ > > arts_users.mi mailing list > > arts_users.mi@lists.uni-hamburg.de > > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi > > > > > > > > -- > > = > > Jana Mendrok, Ph.D. (Project Assistent) > > Chalmers University of Technology > > Earth and Space Sciences > > SE-412 96 Gothenburg, Sweden > > > > Phone : +46 (0)31 772 1883 > > = > > -- = Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
Re: [arts-users] calculate absorption coefficients from abs_coefCalc
Dear Pengwang, please take a look at the workspace variable propmat_clearsky_field (and the workspace method propmat_clearsky_fieldCalc, that calculates this variables). Could they probably provide the output you need? abs_coef and its *Calc method are obsolete and not supported anymore. Best wishes, Jana On Mon, Feb 15, 2016 at 4:30 PM, Pengwang Zhai wrote: > Hi, > > I used earlier version of ARTS to calculate the total absorption > coefficients with: > > abs_coefCalc > > and found it is very useful. Now with the new version, this does not work > any more. After reading the change log I found that it is replaced with > > abs_coefCalcFromXsec > > However, after numerous attemps I could not make this method working for > me. Would you please provide a template arts file on the usage of this > method? > > Thanks very much and hope all the best, > > Yours > > ___ > arts_users.mi mailing list > arts_users.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi > -- ===== Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
