Re: [arts-users] ECMWF IFS ERESMA PROFILES

[Oliver Lemke]

Hi Gianluigi,

> On 14 Sep 2021, at 15:29, gianluigi.libe...@artov.ismar.cnr.it wrote:
> 
> 
> Hi,
> 
> I was trying to converts the xml output of 'extract_arts_l137.f90' to ARTS 
> compatible data format ArrayOfGriddedField4 with the script:
> 
> ./arts/build/src/arts 
> arts-xml-data/planets/Earth/ECMWF/IFS/Eresmaa_137L/ConvertCompactAtm_ArrayOfMatrix-to-ArrayOfGriddedField4.arts

The latest version (2.4.0) of arts-xml-data[1] already contains the XML files 
in the correct format. You don't need to run the conversion yourself.

[1] https://radiativetransfer.org/misc/download/stable/2.4/

> first the script call twice the method
> 
> StringCompose
> 
> that is not recognized so I substitute it with
> 
>  StringJoin
> 
> but it is not yet working and it gives me the following error

Thanks for pointing this out. We missed this when the StringCompose method was 
renamed. I've committed a fix for that in our svn.

> OUTPUT
> 
> [snip]
> Cannot find input file: ./eresmaal137_all_ccol.xml.temp
> [snip]
> 
> END OUTPUT
> 
> what should be in the file eresmaal137_all_ccol.xml.temp

The file is generated by the Fortran program extract_arts_l137.f90. But it 
needs the original ERESMAA profiles provided by NWP SAF as input. The original 
data is not included in arts-xml-data. As mentioned above, I don't think you 
need to do this. The manual conversion would just give you the same xml data 
files which are already present in that directory.

Cheers,
Oliver


___
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] PhD position in Atmospheric Science, located in Kiruna, Sweden

[Oliver Lemke]

The atmospheric science research group at Luleå University of Technology has an 
 open PhD position at the Campus in Kiruna, Sweden.


The project consists of two, closely related parts. In-situ measurements on 
cirrus clouds which will provide a database of various microphysical properties 
of cirrus particles, providing optical properties which are relevant for lidar 
observations. The second part will focus on measurements with a ground-based 
lidar, located at the Swedish Institute of Space Physics (IRF) in Kiruna. 
Parameters from the database of microphysical properties will be utilised to 
analyse lidar observations. The resulting cirrus properties in turn will be 
compared with data products from the ATLID instrument on the EarthCARE 
satellite, the goal being validation of ATLID data products.
 
For more information and applications, please see
https://www.ltu.se/ltu/Lediga-jobb?l=en
 
Application deadline is August 23, 2021.

___
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] AVHRR example

[Oliver Lemke]

Hi Gian,The AVHRR example is indeed currently broken. Thanks for reporting this.Attached you can find two updated .arts files that you can drop into the instruments/avhrr folder.Also attached you find a python plotting script that shows how the channel/view/profile data is organized in the ybatch output file.Note that for realistic calculations you should replace the example catalog by a full catalog from arts-xml-data in avhrr_reference.arts lines 47-49.Cheers,OliverOn 6 Jul 2021, at 08:11, gianluigi.libe...@artov.ismar.cnr.it wrote:The file 'avhrr_reference.arts' contains the INCLUDE of this two files:INCLUDE "/mnt/hgfs/Condivisa_VM-WIN/RTMS/ARTS/arts-2.4.0/controlfiles/instruments/hirs/hirs_general.arts"INCLUDE "/mnt/hgfs/Condivisa_VM-WIN/RTMS/ARTS/arts-2.4.0/controlfiles/instruments/hirs/hirs_spectroscopy.arts"that are not available in the expected directory neither in the whole .tarAre these files available somewhere?thank youG.L.Liberti

avhrr_reference.arts
Description: Binary data


TestAVHRR.arts
Description: Binary data
import matplotlib.pyplot as plt
import pyarts

y = pyarts.xml.load("./TestAVHRR.ybatch.xml")
views = pyarts.xml.load("./TestAVHRR.views.xml")

plt.plot(views, y[0][0::2], marker="o", label="Channel 1, Profile 1")
plt.plot(views, y[0][1::2], marker="x", label="Channel 2, Profile 1")
plt.plot(views, y[1][0::2], marker="o", label="Channel 1, Profile 2")
plt.plot(views, y[1][1::2], marker="x", label="Channel 2, Profile 2")
plt.xlabel("View index")
plt.ylabel("Brightness temperature / K")
plt.legend()
plt.savefig("avhrr.pdf")
plt.show()


avhrr.pdf
Description: Adobe PDF document
___
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] link in user manual

[Oliver Lemke]

Hi Gian,

The docserver has moved to github pages. You can find all documentation for the 
current stable version here:

https://atmtools.github.io/arts-docs-2.4/

and for the development version here:

https://atmtools.github.io/arts-docs-master/

We will update the links in the user guide with the next release.

Cheers,
Oliver


> On 30 Jun 2021, at 09:51, gianluigi.libe...@artov.ismar.cnr.it wrote:
> 
> Hello,
> 
> the links in the user manual, as for example:
> 
> https://www.radiativetransfer.org/docserver-trunk/all/sensor_los
> 
> do not link to the documentation page. Which one is the correct link?
> 
> Thanks
> G.L.Liberti
> ISMAR-CNR
> 
> 
> 
> ___
> 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

Re: [arts-users] Query on ARTs cross section files

[Oliver Lemke]

Hi Songyan,

Great to hear that you're working with CFCs. Your question comes at an (almost) 
perfect time. :-)

We are right now working on bringing all the pieces together to provide an 
improved implementation of the cross section model in the development version 
of ARTS. It should be available within the next two weeks.

The required XML input files for the new model will be provided in our 
arts-xml-data package.

Since we consider the implementation in ARTS v2.4 as experimental and more as a 
proof of concept, I would recommend that you wait a couple of days until the 
new version is ready.

We would very much appreciate if you consider using the new model for your 
work. Your feedback would also be very valuable for us.

I'll keep you posted.

Cheers,
Oliver


> On 22 Jun 2021, at 09:51, Zhu, Songyan  wrote:
> 
>  
> Dear ARTs team,
>  
> My name is Songyan Zhu, a Phd student at the University of Exeter, UK.
>  
> I’m using ARTs to simulate impacts of CFCs on the climate in infra-red.
> However, ARTs v2.4 requires the cross section files in xml format, but 
> available cross sections from HITRAN are in xsc.
> So I’m wondering is there anyway I can convert the xsc files into xml or some 
> place where I can find xml cross sections?
>  
> Best, Songyan 
> ___
> 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

Re: [arts-users] Problem about caculating the impact of winds

[Oliver Lemke]

Hi Wang,

How do you setup the f_grid for the y calculation? Depending on how you 
generate the f_grid for y, it might end up with a value that lies just a bit 
outside the boundary of the f_grid used for the lookup table due to slight 
numerical inaccuracies. These inaccuracies can be depending on your chosen step 
size. That could explain why it works for 2 MHz, but not for 1 MHz.

You can try to extend your lookup table grid a little bit to ensure that your 
new f_grid lies inside of it.

Cheers,
Oliver


> On 21 Apr 2021, at 07:59, Wenyu Wang  wrote:
> 
> Hi Everyone,
> 
> I had a question about caculating the impact of winds by using lookup table 
> in ARTS.
> 
> 
> 
> I use the larger frequency grid when generate the table, such as 3 GHz band, 
> 0.5 MHz setp. However, when I caculate the y using the frequency grid with 1 
> GHz band and 1 MHz step, error messages occur as  follow (But it is OK when I 
> set the frequency step to 2 MHz):
> 
> 
> 
> Runtime-error in source calculation at index 0: 
> Run-time error in agenda: propmat_clearsky_agenda
> Run-time error in method: propmat_clearskyAddFromLookup
> Problem with gas absorption lookup table.
> At least one frequency is outside the range covered by the lookup table.
> 
> 
> 
> The version of ARTS  is 2.4.0.
> 
> 
> 
> Regards,
> 
> Wang
> 
> ___
> 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

Re: [arts-users] Some questions about absorption model

[Oliver Lemke]

Hi,

Answering your second question, you can add SurfaceDummy to your 
iy_surface_agenda. See here:

https://atmtools.github.io/arts-docs-2.4/docserver/methods/SurfaceDummy.html

Cheers,
Oliver


> On 30 Oct 2020, at 08:48, Wenyu Wang  wrote:
> 
> Dear Everyone,
> 
> I had some questions:
> 
> 
> 
> 1. When I using line-by-line and MPM93（or PWR98） to calculate the brightness 
> temperatures, the difference between the results can be more than 20 K at 
> about 50 and 70 GHz in the nadir observation (especially when the 
> reflectivity is large). Is this expected ? In other frequencies, such as 118 
> GHz, the difference is small.
> 2. when I using iy_surface_agenda in 2.4.0 (but it can be worked in arts 
> 2.3), error will occur:
> 
> Run-time error in method: AgendaSet
> The agenda iy_surface_agenda must generate the output WSV 
> dsurface_rmatrix_dx,but it does not. 
> 
> How can I solve it?
> 
> 3. I extracted the scat data from the Single Scattering Databases. In the 
> test controlfiles, the data is read as:
> 
> ScatElementsPndAndScatAdd( 
>   
> scat_data_files=["testdata/scatData/azi-random_f229-231T214-225r100NP-1ar1_5ice.xml"],
>   pnd_field_files=[""]
> )
> 
> However, the data from the Single Scattering Databases can't be read by this 
> method since the format is different. Should I use ScatSpeciesScatAndMetaRead 
> instead? 
> 
> Thank you very much. It is better if a demo contralfile could be provided. 
> 
> Regards,
> 
> Wenyu Wang
> 
> ___
> arts_users.mi mailing list
> arts_users.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi



smime.p7s
Description: S/MIME cryptographic signature
___
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] ARTS 2.4.0 Release

[Oliver Lemke]

Dear ARTS community,

Today we're happy to announce the release of ARTS 2.4. Since the last release 
in 2014, development has carried on and many new features and improvements have 
found its way into ARTS. Below you find a list of the most important changes.

Links to source code and documentation can be found on our homepage:

https://www.radiativetransfer.org/getarts/#stable

Updated atmlab and arts-xml-data packages are available as well:

https://radiativetransfer.org/tools/

Thanks to all of you who have been using ARTS in the past years for their 
science. We're looking forward to your feedback and contributions.


Key features


- New improved format for line-by-line data
- Non-LTE (pure-rotational non-overlapping, and non-chemical cases)
- Dedicated methods for heating rate calculations
- Basic simulations of radars (both single and multiple scattering)
- Radio link calculations not supported in this version
- Interfaces to DISORT and RT4 scattering solvers
- Jacobian for new quantities:
 - spectroscopic variables
 - particle properties (approximative)
- OEM type inversions inside ARTS
- TELSEM and TESSEM surface models
- PyARTS: Python bindings for ARTS


General
===

- Radiative transfer code (except MC) totally revised, including:
 - Higher consistency between modules
 - Higher calculation efficiency
 - Jacobian of atmospheric variables now fully analytical
- Absorption/LBL revised
 - Support for new lineshapes
 - Performance improvements
- New and extended system for defining particle size distributions
- DOIT improvements
 - Optimized pressure grid
 - Convergence acceleration
 - Optional precalculated first-guess field
- New sensor setup for passband-type, meteorological millimeter
 instruments (sensor_responseMetMM)


Known Issues


- TestSpectroscopy fails on macOS


Stay healthy and enjoy,
The ARTS Developers



smime.p7s
Description: S/MIME cryptographic signature
___
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] 52% of CTEST fails during ARTS compilation

[Oliver Lemke]

Hi Reno,

> On 9 Oct 2020, at 09:56, Reno Choi  wrote:
> 
> Hi Oliver,
> 
> Many thanks for the prompt response. Sounds like it's CTEST, not a compile 
> process.
> 
> I followed your 1st test and showed 3 tests failed out of 71,
> 
> 66 - arts.ctlfile.fast.artscomponents.helpers.TestRegridding (Failed)
> 70 - arts.ctlfile.fast.artscomponents.wfuns.TestSpectroscopy (Failed)
> 71 - arts.ctlfile.fast.artscomponents.cia.TestCIADerivs (Failed)
> 
> Because of the following missing xml and data files, respectively.
> 
> Cannot find input file: spectroscopy/cia/borysow/Borysow_CIA_JUICE_SWI.xml
> Cannot find input file: spectroscopy/PartitionSums/TIPS/tips.xml
> Cannot find input file: 
> planets/Earth/ECMWF/ERA40/SurfaceAltitude_ERA40_1.0Degree
> 
> Full screenshot is attached in "arts_make_check_results.txt".

Since you're using the latest ARTS, you also have to make sure that you check 
out the latest arts-xml-data from our subversion repository. According to the 
path you specify in your cmake call, your still using arts-xml-data 2.2.5. You 
can check out the current arts-xml-data with:

svn co https://arts.mi.uni-hamburg.de/svn/rt/arts-xml-data/trunk arts-xml-data

> The 2nd test(make check-all) was carried out and 23 tests failed out of 225. 
> This is far better than my earlier report and almost all were due to missing 
> input files (Can you tell me where they are, btw?). The full screenshot is 
> also attached herewith as "arts_make_check-all_results.txt".
> 
> One thing that caught my eyes was at "arts_convert" during the "make 
> check-all" process. It looks like arts' workspace methods are not well 
> understood in converting into Python. Is my understanding correct? and are 
> they to be examined before I use Pyarts?

The conversion script currently just tries to convert every .arts controlfile 
it can find. The once that are failing are outdated and will be removed. It's 
safe to ignore these conversion failures for now. They have no impact on PyARTS.

Cheers,
Oliver



smime.p7s
Description: S/MIME cryptographic signature
___
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] 52% of CTEST fails during ARTS compilation

[Oliver Lemke]

Hi Reno,

It looks like all the Python related tests are failing. This is currently a 
flaw in our build setup when calling 'ctest' manually. It circumvents the 
dependency tracking of 'make' and doesn't trigger the conversion of the 
controlfiles to Python. Try to use the provided check targets instead:

For basic controlfile checks:

make check

Now TestSpectroscopy should be the only test failing (due to differences in the 
math library on macOS, we're aware of this issue).

For all checks:

make check-all

To speed up the test execution, like you did by passing '-j4' to 'ctest', you 
can instead add the option '-DTEST_JOBS=4' to your 'cmake' command.

Hope this helps.

Cheers,
Oliver


> On 9 Oct 2020, at 05:39, Reno Choi  wrote:
> 
> Hello,
> 
> I've recently compiled the latest ARTS from GitHub and found many errors from 
> CTEST.
> 
> The ARTS are installed on my MacBook Pro, with the following environment,
>   • Catalina OSX v.10.15.7 with the latest Xcode 12.0.1 (12A7300)
>   • gcc/g++/gfortran 10.2.0 from Homebrew*
>   • Anaconda3
>   • MecTex
>   • and, all prerequisites shown in README.md
> * Add additional library and include path for the compiler to find the system 
> headers and libraries.
> >export 
> >LDFLAGS="-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
> >export 
> >CPPFLAGS="-I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include"
> 
> For cmake, 
> 
> > cmake -DARTS_XML_DATA_PATH=/Users/reno/Work/arts-xml-data-2.2.5 
> > -DWITH_HITRAN2008=0 -DENABLE_FORTRAN=1 
> > -DCMAKE_Fortran_COMPILER=/usr/local/Cellar/gcc/10.2.0.reinstall/bin/gfortran-10
> >  -DENABLE_TMATRIX_QUAD=0 
> > -DCMAKE_C_COMPILER=/usr/local/Cellar/gcc/10.2.0.reinstall/bin/gcc-10 
> > -DCMAKE_CXX_COMPILER=/usr/local/Cellar/gcc/10.2.0.reinstall/bin/g++-10 
> > -DENABLE_NETCDF=1 -DFASTWIGNER=1 ..
> 
> The cmake results are attached in 'arts_cmake_results.txt', which was 
> successful. Then, went for make,
> 
>  > make -j9
> 
> The screen capture are in 'arts_compile_results.txt'. The executable files 
> were generated, whie with a number of warnings (~100).
> 
> > ./arts -v
> arts-2.3.1287 (git: 60279fd2) (compiled Fri Oct  9 01:07:03 2020)
> Compiler: GNU 10.2.0 (/usr/local/Cellar/gcc/10.2.0/bin/g++-10)
> Compile flags:  -fvisibility=hidden -fvisibility-inlines-hidden 
> -ftemplate-depth-1024 -fopenmp  -W  -Wall  -Wshadow  -Wconversion  
> -Wno-sign-conversion  -Wno-unknown-pragmas  -Wno-strict-overflow   -O2 -g
> Features in this build:
>Numeric precision:double
>OpenMP support:   enabled
>Documentation server: enabled
>Zipped XML support:   enabled
>NetCDF support:   enabled
>Fortran support:  enabled (gfortran-10)
>Legacy Fortran Disort:disabled
>RT4 support:  enabled
>FASTEM support:   enabled
>OEM support:  enabled
>MPI support for OEM:  disabled
>Refice support:   enabled
>Tmatrix support:  enabled (double-precision)
>Hitran Xsec support:  enabled (experimental)
> Include search paths:
>.
>/Users/reno/Work/arts/controlfiles
> Data searchpaths:
>.
> 
> Now, I ran CTEST and results showed 108 tests failed out of 225. The 
> screenshot of CTEST results can be found in "arts_ctest_results.txt". I 
> carried out a single CTEST to see in detail,
> 
> (base) reno@Renos-MBP build % ctest -R TestForloop
> Test project /Users/reno/Work/arts/build
> Start 10: arts.ctlfile.fast.artscomponents.helpers.TestForloop
> 1/2 Test #10: arts.ctlfile.fast.artscomponents.helpers.TestForloop .. 
>   Passed0.04 sec
> Start 11: python.arts.ctlfile.fast.artscomponents.helpers.TestForloop
> 2/2 Test #11: python.arts.ctlfile.fast.artscomponents.helpers.TestForloop 
> ...***Failed0.03 sec
> 50% tests passed, 1 tests failed out of 2
> Total Test time (real) =   0.09 sec
> The following tests FAILED:
> 11 - python.arts.ctlfile.fast.artscomponents.helpers.TestForloop (Failed)
> Errors while running CTest
> 
> Nonetheless, I wondered if any example controlfiles were working. I tried 
> "TestAbs.art" and it seemed ok to me (please, see attached 
> "arts_TestAbs.arts_results.txt").
> 
> So far, I am curious if my compilation was successful or not. What does 52% 
> of CTEST fails mean? Am I missing anything at all?
> 
> I wonder if anyone in this community has similar experience or comments to 
> share.
> 
> Regards,
> Reno
> 
> 
> -- 
> Reno K.-Y. Choi, PhD
> 
> M. (+82 0)10 4570 9066
> O. (+82 0)64 780 6618
> M. (+44 0)7946 459 108
> ___
> arts_users.mi mailing list
> arts_users.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi



smime.p7s
Description: S/MIME cryptographic signature
___
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] Downloading Data from ARTS

[Oliver Lemke]

Dear Frances,

The catalogues provided for download are targeted for the matching stable 
version of ARTS (2.2) which does not support ARTSCAT-5. If you're using the 
development version of ARTS from GitHub, you need to check out the current 
version of arts-xml-data from the subversion repository:

svn co https://arts.mi.uni-hamburg.de/svn/rt/arts-xml-data/trunk/ arts-xml-data

Please note that the catalog format is currently undergoing another revision 
and things might be a bit rough around the edges as expected in a development 
version.

Cheers,
Oliver


> On 8 Jun 2020, at 22:20, Skinner, Frances  
> wrote:
> 
> Hello,
> 
> I am a new user of ARTS and I have a question regarding downloading ARTSCAT-5 
> XML Files from the radiative transfer website. I downloaded the three data 
> files at https://www.radiativetransfer.org/misc/download/stable/2.2/ and 
> noticed that they all contain ARTSCAT-4 data instead of version 5 (In the 
> spectroscopy folder under Perrin). I also noticed this same issue at the 
> webpage 
> https://arts.mi.uni-hamburg.de/svn/rt/arts-xml-data/branches/arts-xml-data-2.2/spectroscopy/Perrin/.
>  I was hoping to locate the ARTSCAT-5 data since using the ARTSCAT-4 data 
> gives me an assertion error and a statement that I can only use ARTSCAT5 
> data. 
> 
> I am using Typhon for reading and writing routines for ARTS XML files. Thank 
> you for your time and assistance, I am happy to provide any additional 
> information about my error if further clarification is needed. 
> 
> Kind Regards,
> Frances Skinner




smime.p7s
Description: S/MIME cryptographic signature
___
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] ARTS workshop

[Oliver Lemke]

Dear Sisma,

A workshop announcement has been sent to the mailing lists earlier this month. 
If you haven't received that mail, you can find all information also in the 
latest news item on our homepage:

http://www.radiativetransfer.org 

Cheers,
Oliver


> On 14. Feb 2020, at 12:53, Sisma Samuel  wrote:
> 
> dear,
> How to apply for arts workshop that will be held June 2020, does any 
> notification came or the date to apply is over
> 
> 
> thanks
> sisma
> ___
> 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

Re: [arts-users] writeOut/readIn error

[Oliver Lemke]

Hi Rita,

First of all thank you very much for including a working test case. :-)

There is indeed a bug in the ReadXML routine for the CovarianceMatrix. Instead 
of overwriting the workspace variable with the contents from the file, it was 
appending the blocks to the existing covmat_sx, ending up with 6 blocks after 
reading instead of 3.

I will commit a fix soon.

As a workaround in your version, you can delete the covmat_sx WSV before 
reading it:

WriteXML( "ascii", covmat_sx, "covmat_sx1.xml")
Delete(covmat_sx)
ReadXML( covmat_sx, "covmat_sx1.xml")

Thanks a lot for reporting this.

Cheers,
Oliver


> On 14. Jan 2020, at 21:17, Rita Kajtar  wrote:
> 
> Hello! 
> 
> 
> In one of my tests with TestOEM.arts if I add: 
> 
> WriteXML( "ascii", covmat_sx, "covmat_sx1.xml")
> ReadXML( covmat_sx, "covmat_sx1.xml") 
> 
> right after the retrieval quantities definition, but before retrievalDefClose 
> (file attached) in TestOEM.arts, I get the message included below. 
> I have also tried considering a binary format instead of ascii and I get the 
> same error message. 
> 
> Is it possible to have a bug in the Write/Read methods?
> 
> 
> 
> 
> 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

___
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] cloudy simulations with ARTS

[Oliver Lemke]

Hi Paolo,

For blas and lapack: Please make sure you have the libraries and development 
header files installed. I think the packages you have to install with yum on 
CentOS are called lapack-devel and libblas-devel. Having those hopefully fixes 
the compilation with GCC.

Since we use GCC and LLVM for development, the Intel Compiler is currently not 
tested for the development version. I recommend to stick with GCC for now.

Cheers,
Oliver


> On 3. Dec 2019, at 20:07, PAOLO VEGLIO  wrote:
> 
> Patrick,
> yes, I got a few complains by arts about variables/methods not being defined 
> if I try to use v2.2.64.
> 
> I was just looking at the development version today, but I have some issues 
> compiling it (on Linux CentOS 7). I made sure that my machine meets all the 
> requirements but I get a couple different errors, depending on whether I’m 
> using gcc or the intel compiler.
> Namely, if I use gcc, cmake can’t find lapack. This is the message I get when 
> I run cmake:
> 
> CMake Error at cmake/modules/FindBLAS.cmake:699 (message):
>   A required library with BLAS API not found.  Please specify library
>   location.
> Call Stack (most recent call first):
>   cmake/modules/FindLAPACK.cmake:162 (find_package)
>   CMakeLists.txt:248 (find_package)
> I’d provide cmake with the path to my lapack but I’m not sure how to do it. 
> Given what follows though, I’m not sure I would be able to compile the code 
> anyway.
> Cmake works if I use the intel compiler, but then the compilation fails with 
> this error:
> 
> [  8%] Built target microhttpd
> Scanning dependencies of target matpack
> [  8%] Building CXX object src/CMakeFiles/matpack.dir/complex.cc.o
> icpc: command line warning #10121: overriding '-std=c++11' with '-std=c++14'
> /home/pveglio/arts/src/complex.cc (1529): error: more 
> than one operator "*" matches these operands:
> function "std::operator*(const std::complex &, const 
> std::complex &)"
> function "operator*(Complex, Complex)"
> operand types are: const Complex * const Complex
> for (; ai != ae; ++ai, ++bi) res += (*ai) * (*bi);
>   ^
> 
> [...]
> 
> compilation aborted for /home/pveglio/arts/src/complex.cc 
>  (code 2)
> make[2]: *** [src/CMakeFiles/matpack.dir/complex.cc.o] Error 2
> make[1]: *** [src/CMakeFiles/matpack.dir/all] Error 2
> make: *** [all] Error 2
> 
> there’s a whole lot in between but I can’t tell if it could be useful or it’s 
> just the same error propagating throughout the code.
> 
> Let me know if you have any idea of what could cause these errors or you need 
> more information.
> Thanks,
> 
> Paolo
> 
> 
> Paolo Veglio, Ph.D.
> Space Science and Engineering Center
> University of Wisconsin - Madison
> 1225 W. Dayton St.
> Madison WI 53706, USA
> 
>> On Dec 3, 2019, at 12:33 PM, Patrick Eriksson > > wrote:
>> 
>> Paolo,
>> 
>>> And yes, these controlfiles seem to be available only in the development 
>>> version of ARTS, but I assume I can use them with the latest stable version 
>>> as well.
>> 
>> Sorry, but that is not the case. There are features used in those cfiles 
>> that are not at hand in v2.2.
>> 
>> In general, as you are interested in simulations around ICI, I would suggest 
>> that you switch to the development version. We have added quite a lot around 
>> scattering calculations since v2.2.
>> 
>> 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

___
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] cmake error upon build on new os

[Oliver Lemke]

Hi Victoria,

You have to completely empty the build directory and run cmake again. Also make 
sure that you have updated Xcode and agreed to the current license. 'sudo 
xcodebuild -license accept'

Cheers,
Oliver


> On 26. Nov 2019, at 01:55, Victoria Sol Galligani 
>  wrote:
> 
> Hi! I have recently updated my system OS and upon the installation of the 
> latest version of ARTS i've run into the following configuration error. What 
> do you suggest I try?
> Thank you! 
> Victoria
> 
> 
> CMake Error at /usr/local/share/cmake-3.5/Modules/Platform/Darwin.cmake:76 
> (message):
>   CMAKE_OSX_DEPLOYMENT_TARGET is '10.14' but CMAKE_OSX_SYSROOT:
> 
>""
> 
>   is not set to a MacOSX SDK with a recognized version.  Either set
>   CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to
>   empty.
> Call Stack (most recent call first):
>   /usr/local/share/cmake-3.5/Modules/CMakeSystemSpecificInformation.cmake:36 
> (include)
>   CMakeLists.txt:45 (project)
> 
> 
> 
> 
> ___
> 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

Re: [arts-users] Write single scattering properties for ARTS with typhon

[Oliver Lemke]

Hi Frank,

To initialize the SSD from a dictionary, you can use the from_data classmethod. 
Also note that using integer numbers for ptype is obsolete, they have been 
replaced by strings ("general", "totally_random", "azimuthally_random" for 
version 3 of the SSD).

Here's an example with data dimensions adjusted for the azimuthally random case:

import typhon
import numpy as np

params = {'f_grid': [1740.0, 2100.0],
  'T_grid': [190, 200, 210, 220.0, 230],
  'za_grid': [0,  10,  20,  30,  40,  50,  60,  70,  80,  90, 100, 110, 
120, 130, 140, 150, 160, 170, 180],
  'aa_grid': [0,  10,  20,  30,  40,  50,  60,  70,  80,  90, 100, 110, 
120, 130, 140, 150, 160, 170, 180],
  'aspect_ratio': 1.5,
  'NP': -1, 'precision': .001,
  'phase': 'ice',
  'ptype': 'azimuthally_random',
  'equiv_radius': 100}

scatt_data = typhon.arts.scattering.SingleScatteringData.from_data(params)
scatt_data.pha_mat_data = np.zeros(
(len(params['f_grid']), len(params['T_grid']),
 len(params['za_grid']), len(params['aa_grid']), len(params['za_grid']), 1, 
16))
scatt_data.ext_mat_data = np.zeros(
(len(params['f_grid']), len(params['T_grid']),
 len(params['za_grid']), 1, 3))
scatt_data.abs_vec_data = np.zeros(
(len(params['f_grid']), len(params['T_grid']),
 len(params['za_grid']), 1, 2))

typhon.arts.xml.save(scatt_data, 'scattering.xml')


Cheers,
Oliver


> On 15. Nov 2019, at 19:31, Werner, Frank (329D)  
> wrote:
> 
> Hi all,
>  
> For some ARTS runs including scattering by cirrus I am trying to create and 
> write single scattering properties with the module ‘SingleScatteringData’ 
> from the typhon package. Unfortunately, I cannot seem to get the syntax right 
> (just calculating the data, not even writing it into an xml file). A very 
> simple example would be highly appreciated. Here is what I tried to do:
>  
> import typhon 
> params = {'f_grid':[1740.0, 2100.0],'T_grid':[190,200,210, 
> 220.0,230],
> 'za_grid':[0,  10,  20,  30,  40,  50,  60,  70,  80,  90, 100, 110, 120, 
> 130, 140, 150, 160, 170, 180],
> 'aa_grid':[0,  10,  20,  30,  40,  50,  60,  70,  80,  90, 100, 110, 120, 
> 130, 140, 150, 160, 170, 180],
> 'aspect_ratio':1.5,'NP':-1,'precision':.001,'phase':'ice','ptype':30,'equiv_radius':100}
>  
> scatt_data  = typhon.arts.scattering.SingleScatteringData (params)
>  
> This yields the error:
>  
> ‘TypeError: __init__() takes 1 positional argument but 2 were given’. This is 
> probably a trivial issue; the possible parameters are described in the user 
> manual. I just cannot seem to invoke the function correctly.
>  
> Thanks for your help and best wishes,
> Frank
>  
> -- 
> Frank Werner
> Mail Stop 183-701, Jet Propulsion Laboratory
> 4800 Oak Grove Drive, Pasadena, California 91109, United States
> Phone: +1 818 354-1918
> Fax: +1 818 393 5065
> ___
> 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

[arts-users] ARTS Microwave Single Scattering Properties Database (Oriented Particles) Version 1.0 released

[Oliver Lemke]

Hi all,

We are pleased to announce that the ARTS Microwave Single Scattering Properties 
Database (Oriented Particles) has been released and is available for download 
on Zenodo[1].

The database contains microwave and submillimeter wave single scattering data 
of azimuthally randomly oriented frozen hydrometeors. It contains one aggregate 
habit and one pristine ice crystal habit. Furthermore, 35 frequencies from 1 to 
886 GHz, and 3 temperatures, 190, 230 and 270 K, are included. 

The Python3 interface of ARTS Microwave Single Scattering Properties Database 
Interfaces[2] can be used for browsing and importing of the single scattering 
data of azimuthally randomly oriented.

Information and download links can also be found in the tools section of the 
ARTS webpage[3].

Best wishes,
The ARTS Developers


[1] https://doi.org/10.5281/zenodo.3463003
[2] https://doi.org/10.5281/zenodo.1175588
[3] http://www.radiativetransfer.org/tools/#ssd



smime.p7s
Description: S/MIME cryptographic signature
___
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] ARTS in Ubuntu 18.04

[Oliver Lemke]

Hi Yuriy,

> On 19 Sep 2019, at 18:37, Goncharenko,Yuriy  
> wrote:
> 
> Hi Oliver,
> 
>   I guess, I have found the origin of the issue:
> 
>   I'm still in my home directory (/home/yuriy) after I did "git clone" and I 
> did not move to /home/yuriy/arts.
>   It means that mkdir -p build makes the directory /home/yuriy/build instead 
> of /home/yuriy/arts/build
>   Basically, to fix this, user should only run cd arts before making the 
> directory /build   

I've updated the instructions on the webpage and the README in the master 
branch to make that point clearer. Although this doesn't explain the error you 
were seeing initially about the missing include files either. Creating the 
build directory directly in home and then running 'cmake ..' inside it, cmake 
would've just straight up complained that there is no CMakelists.txt in the 
parent directory. :-)

>   Probably, the error below also linked to some folder mismatch.  
> Hopefully, it is not the end of the world (hopefully I could download all 
> pdfs from the website)  
> 
> make
> 
> [NUMBER OR WARNINGS BUT IT COMPILES]
> 
> ! LaTeX Error: File `paralist.sty' not found.
> 
> [snip]

The paralist package is not part of Ubuntu's texlive default installation:

➜ apt-cache search paralist
texlive-latex-extra - TeX Live: LaTeX additional packages 

Install the texlive-latex-extra package to get ahold of the missing paralist 
package. I've tested this on 19.10, but it should be included in 18.04 as well.

> PS1: Just in case, This is the list of libraries required to compile ARTS in 
> Ubuntu 18.04. Hopefully it could save some time for other users.
> 
>libblas-dev, zlib1g, cmake, libnetcdf-dev, libnetcdff-dev, texlive, doxygen

We've been reluctant to add distribution specific package install instructions 
to our documentation in the past. The reason being the vast amount of different 
distributions out there and packages are named differently in different 
distros. But I can see your point that figuring out which packages need to be 
installed might not be straightforward. Adding a separate DEPENDENCIES file 
with that information is something we're considering.

> PS2: Could you include my address into the list arts-users mailing list to 
> get the access to arts_users.mi Archives? I tried few times but my 
> email/password is still inactive.

I've added you to the list now and you should've received a confirmation mail. 
There is also a searchable, public archive of the list available at:

https://www.mail-archive.com/arts_users.mi@lists.uni-hamburg.de/

Thanks a lot for your feedback.

Cheers,
Oliver


> On 9/19/2019 12:11 AM, Oliver Lemke wrote:
>> Hi Yuriy,
>> 
>> 
>>> On 19 Sep 2019, at 00:36, Goncharenko,Yuriy 
>>> 
>>>  wrote:
>>> 
>>> Hi Oliver,
>>> 
>>>   it looks like the module path is set wrong. Basically, the source 
>>> directory is set
>>> as /home/yuriy/  instead of /home/yuriy/arts/
>>> 
>> Great that it works now.
>> 
>> 
>>> I believe it happened because I use 
>>> cmake .. 
>>> (as it was suggested at the ARTS website) instead of
>>> cmake /home/yuriy/arts/
>>> 
>>> (as it was suggested in CMakeLists.txt)
>>> 
>> There must be something else going on because running 'cmake ..' after 
>> cd'ing into the 'build' directory worked on every configuration we have 
>> encountered in testing so far.
>> 
>> One more question concerning your setup (so I can reproduce it for testing): 
>> Are you using Ubuntu as a standalone Virtual Machine (vmware, virtualbox) or 
>> did you install the Ubuntu App from the Microsoft Store?
>> 
>> Thanks for pointing out this issue.
>> 
>> Cheers,
>> Oliver
>> 
>> 
> 
> ___
> arts_users.mi mailing list
> arts_users.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi



smime.p7s
Description: S/MIME cryptographic signature
___
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] ARTS in Ubuntu 18.04

[Oliver Lemke]

Hi Yuriy,

> On 19 Sep 2019, at 00:36, Goncharenko,Yuriy  
> wrote:
> 
> Hi Oliver,
> 
>   it looks like the module path is set wrong. Basically, the source directory 
> is set
> as /home/yuriy/  instead of /home/yuriy/arts/

Great that it works now.

> I believe it happened because I use 
> cmake .. 
> (as it was suggested at the ARTS website) instead of
> cmake /home/yuriy/arts/
> 
> (as it was suggested in CMakeLists.txt)

There must be something else going on because running 'cmake ..' after cd'ing 
into the 'build' directory worked on every configuration we have encountered in 
testing so far.

One more question concerning your setup (so I can reproduce it for testing): 
Are you using Ubuntu as a standalone Virtual Machine (vmware, virtualbox) or 
did you install the Ubuntu App from the Microsoft Store?

Thanks for pointing out this issue.

Cheers,
Oliver



smime.p7s
Description: S/MIME cryptographic signature
___
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] ARTS in Ubuntu 18.04

[Oliver Lemke]

Hi Yuriy,

Not sure what causes this. Let's first of all check if the module path is set 
correctly. Please make the following change to arts/CMakeLists.txt:

Replace line ~90:

set (CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/modules")

With:

message("@@@ CMP: ${CMAKE_MODULE_PATH}")
set (CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/modules")
message("@@@ CMP: ${CMAKE_MODULE_PATH}")

Now run 'cmake .' in your build directory and check in the terminal output 
whether the value of CMP is really set to /home/yuriy/arts/cmake/modules

Cheers,
Oliver



> On 17 Sep 2019, at 19:46, Goncharenko,Yuriy  
> wrote:
> 
> Hello,
> 
>  I'm trying to install ARTS in Ubuntu 18.04 on Windows VirtualMachine.
> 
>  I got following errors from cmake (ver 3.10.2):
> 
> Make Error at CMakeLists.txt:60 (include):
>   include could not find load file:
> 
> ArtsTestcases
> 
> CMake Error at CMakeLists.txt:144 (include):
>   include could not find load file:
> 
> FindNetCDF
> 
> CMake Error at CMakeLists.txt:171 (include):
>   include could not find load file:
> 
> ArtsAddCompilerFlag
> 
> 
> CMake Error at CMakeLists.txt:178 (ARTS_ADD_COMPILER_FLAG):
>   Unknown CMake command "ARTS_ADD_COMPILER_FLAG".
> 
> all of those files are in: /home/yuriy/arts/cmake/modules
> 
> But cmake can not see them. How to fix this problem?
> 
> Thank you,
>   Yuriy



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Oliver Lemke]

Hi Hugh,

Since ARTS is strongly typed, a Numeric cannot be assigned directly to a Matrix.

But you can extract it into a temporary variable and then use MatrixSetConstant:

Arts2 {

VectorCreate(my_loses)
VectorSet(my_loses, [180,170,160,150,140,130])
Print(my_loses)
IndexSet(ybatch_start, 0)
IndexSet(ybatch_n,6)
NumericCreate(one_los)

AgendaSet(ybatch_calc_agenda){
Extract(one_los,my_loses,ybatch_index)
MatrixSetConstant(sensor_los, 1, 1, one_los)
Print( ybatch_index, 0 )
Print( sensor_los, 0 )
   ## Actual calculations including iyCalc go here

   Touch(y)
   Touch(y_aux)
   Touch(jacobian)
}

ybatchCalc
}


Hope this helps.

Cheers,
Oliver

> On 17 Jul 2019, at 19:20, PUMPHREY Hugh  wrote:
> 
> 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
> }



smime.p7s
Description: S/MIME cryptographic signature
___
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] Does not make

[Oliver Lemke]

Hi Egor,

> On 26 Jun 2019, at 12:09,   
> wrote:
> 
> Dear ARTS users or developers,
>  
> Could you confirm that the model calculates atmospheric transmittances and 
> path radiances for thermal bands (3-15 um)?

3um is at the edge of the range we're usually calculating with ARTS, but 
otherwise it should be fine. Take also into account that ARTS does not support 
a solar source.

> The code does not make. What am I doing wrong?
> I thought that it is due to absence of  NetCDF package (which is optional).
> Anyways, I did not manage to compile the NetCDF4 as well with the same error 
> messages.

If you're using the stable ARTS 2.2 version, try to deactivate the NetCDF 
feature completely by running

cmake -DNO_NETCDF=1 .

in your build directory. It could be that a system-installed NetCDF library was 
auto-detected, but turns out to be incompatible with ARTS.

Cheers,
Oliver


___
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] Running ARTS in several cores

[Oliver Lemke]

Hi Federico,

The behaviour you're seeing is normal. Based on the type of calculation, ARTS 
tries to pick the best place where parallelisation is applied. yCalc for 
example consists of several nested loops. Based on the number of iterations in 
each loop and the number of cores used, it picks one loop on which 
parallelisation is used. If you do a ybatch calculation, the loop over the 
batch cases is always the one that gets vectorised. This is done because 
parallelization introduces some kind of overhead that has less impact on outer 
loops than on inner loops. Since ARTS can't know how long each iteration will 
take, it is assumes that all iterations inside one batch job are equally 
computational expensive. If they're not, it can lead to to effects you're 
seeing. Currently, there is no mechanism available to control the 
parallelisation behaviour from a control file.

If you have a job that is computational expensive and runs for several days, it 
is advisable to split it up into smaller chunks. Not just for performance, but 
also to reduce the risk of losing several days worth of calculations if 
something goes wrong and the output is only written after the batch job has 
completed successfully.

Cheers,
Oliver


> On 17 May 2019, at 04:41, Federico Cutraro  wrote:
> 
> Hello, I am using ARTS to obtain synthetic satellite images from WRF 
> forecast. To increase the speed, I use several cores (20) but I realized that 
> ARTS does not use all the cores during the whole execution. The number of 
> cores employed decrease with time and ended using only one core for a long 
> time. For example, in a run that took 3 weeks, the last week ran in one core. 
> There is a way to use always all the cores or this is normal behaviour?  
> 
> Kind regards,
> Federico


___
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] simulation errors on new compilation of arts

[Oliver Lemke]

Hi Victoria,

> On 8 May 2019, at 23:17, Victoria Sol Galligani 
>  wrote:
> 
> Hi! I have been using arts version arts-2-3-1171 with no problems. I have 
> recently moved on to a new machine and I have compiled and installed the same 
> version.

Strange indeed. Can you please try to run your test case with the latest 
version from trunk and see if the bug is still present there? If it is, please 
provide me the controlfile and input data and I'll have a look at it.

This could be an issue with parallelization, but this is just a wild guess 
since I don't know what your actual calculations inside the ForLoop agenda are 
doing. You could try to run arts with the '-n1' flag to see if the error still 
occurs when only using one processor core.

> I have tried to run the same scripts I was using before and I get the 
> following error when calculating a very simple clear sky run: 
> 
> - ForLoop
>   Executing for loop body, index: 0
>   Executing for loop body, index: 1
>   Executing for loop body, index: 2
> arts: /src/rte.cc:1901: void iy_transmission_mult(Tensor3&, ConstTensor3View, 
> ConstTensor3View): Assertion `nf == iy_trans_new.npages()' failed.
> Aborted (core dumped)
> 
> its strange because some indeces of the loop are run! 
> 
> I have compiled with 
> gcc-7, g++-7, gfortran-7
> 
> and I did get the following at the cmake stage
> -- Could NOT find FFTW (missing: FFTW_LIBRARIES FFTW_INCLUDE_DIR) 

This is safe to ignore if you're not using any cross section species (*-XSEC-*).

> -- Performing Test CCFLAG_Wno-return-type-c-linkage
> -- Performing Test CCFLAG_Wno-return-type-c-linkage - Failed
> -- Performing Test CXXFLAG_Wno-return-type-c-linkage
> -- Performing Test CXXFLAG_Wno-return-type-c-linkage - Failed

These are safe to ignore as well.

> Any ideas? 
> Thank you in advance! 
> V. Galligani

Cheers,
Oliver

___
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] Question abort ARTS

[Oliver Lemke]

Hi Owen,

Does the directory arts/cmake/modules/ exist and does it contain the following 
files?

ArtsAddCompilerFlag.cmake
ArtsBuildTexDoc.cmake
ArtsTestcases.cmake
ArtsVersion.cmake
FindNetCDF.cmake

The only thing I can think of leading to the error you're seeing is that the 
directory or something in it got lost.

How did you obtain ARTS? Did you download a prepackaged version or did you 
check it out from subversion?

Cheers,
Oliver


> On 5 May 2019, at 09:52, Owen York  wrote:
> 
> Hi all!
> 
> When I was building ARTS in my Centos7, there are some error happened 
> after I run "cmake ..", I don't know how to fix it, so I write to you for 
> help. Thanks in advance for your time, please advise me at your convenience. 
> 
> The error report is as fellows.
> 
> [xiao@localhost build]$ cmake ..
> 
> CMake Error at CMakeLists.txt:60 (include):
>   include could not find load file:
> 
> 
> 
> ArtsTestcases
> 
> CMake Error at CMakeLists.txt:144 (include):
>   include could not find load file:
> 
> 
> 
> FindNetCDF
> 
> CMake Error at CMakeLists.txt:171 (include):
>   include could not find load file:
> 
> ArtsAddCompilerFlag
> 
> CMake Error at CMakeLists.txt:178 (ARTS_ADD_COMPILER_FLAG):
>   Unknown CMake command "ARTS_ADD_COMPILER_FLAG".
> 
> -- Configuring incomplete, errors occurred!
> ___
> arts_users.mi mailing list
> arts_users.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi



smime.p7s
Description: S/MIME cryptographic signature
___
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] Fwd: AMSUB how test whether right

[Oliver Lemke]

Hi Sisma,

They look correct as far as I can tell from a quick glance at your screenshot. 
You can check the values yourself by comparing them to the supplied reference 
values in arts/controlfiles/instruments/amsu/TestAMSUB.ybatch.ref.xml . This is 
also done automatically if you run a "make check-all".

Cheers,
Oliver


> On 13 Apr 2019, at 15:26, Sisma Samuel  wrote:
> 
> 
> 
> -- Forwarded message -
> From: Sisma Samuel 
> Date: Fri, Apr 12, 2019 at 9:54 PM
> Subject: AMSUB how test  correct or not
> To: ARTS Users List 
> 
> 
> I compiled testamsub.arts and the values i got is as in fig. attached how to 
> know whether its compiled properly 
> 
> -- 
> Yours faithfully
> Sisma Samuel



smime.p7s
Description: S/MIME cryptographic signature
___
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)

[Oliver Lemke]

Hi Richard,

> On 3 Apr 2019, at 14:03, Richard Larsson  wrote:
> 
> Ps. Oliver, please sent another email when it is fixed.

Since you (and Jana, Lukas and I) received this mail via gmail, I have to 
assume it is fixed. Although it is possible that Google blocks mails depending 
on the sender address. We had that issue some time ago when @yahoo mails that 
went through a mailing list where blocked by Google. We'll find out when Rita 
replies to your mail. I'll keep you posted.

Cheers,
Oliver



smime.p7s
Description: S/MIME cryptographic signature
___
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] Wind calculations (resent)

[Oliver Lemke]

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" 
> 
> 
> 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




smime.p7s
Description: S/MIME cryptographic signature
___
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] FASTEM in ARTS

[Oliver Lemke]

Hi Natalia,

Since you mentioned using classroom exercise #2 from the release package and 
Patrick suggesting to switch to the current development version instead, I'd 
like to point out that the exercises are not part of the ARTS package anymore. 
But you can find a separate arts-lectures package with up to date controlfiles 
in our SVN repository:

svn co https://arts.mi.uni-hamburg.de/svn/rt/arts-lectures/trunk arts-lectures

Cheers,
Oliver


> On 7 Mar 2019, at 20:21, Patrick Eriksson  
> wrote:
> 
> Dear Natalia,
> 
> Try this:
> 
> VectorCreate( trv )
> NumericCreate( wind_speed )
> NumericCreate( wind_dir )
> 
> AgendaSet( iy_surface_agenda ){
>  SurfaceDummy
>  specular_losCalc
>  ppathCalc( rte_pos=rtp_pos, rte_los=specular_los )
>  ArrayOfStringSet( iy_aux_vars, ["Optical depth"] )
>  iyEmissionStandard
>  transmittanceFromIy_aux( transmittance=trv )
>  surfaceFastem( wind_speed=wind_speed, wind_direction=wind_dir, 
> transmittance=trv )
>  iySurfaceRtpropCalc
> }
> 
> This should work. I have not actually made a test run (due to lack of time) 
> but hopefully I have not missed any detail. (If you use this, you can ignore 
> surface_rtprop_agenda).
> 
> FASTEM does not fit into the pattern of ARTS, as it wants the transmission as 
> input. This makes the agenda definition a bit messy.
> 
> FASTEM 6 is default.
> 
> My suggestion uses the default for salinity, adopt if you want to use another 
> value.
> 
> You need a quite recent version of ARTS 2.3 for this. I added the method 
> transmittanceFromIy_aux not a long time ago.
> 
> Bye,
> 
> Patrick
> 
> 
> 
> On 2019-03-07 19:22, Bliankinshtein, Natalia wrote:
>> Dear Patrick,
>> Thanks for your prompt reply! I would like to use FASTEM in a simple 1D 
>> forward model configuration, so no retrievals of surface properties will be 
>> needed. I am particularly interested in FASTEM6 - not sure how its versions 
>> align with those of ARTS. Also, I think a simple prescribing of surface 
>> wind, temperature and salinity as Numerics would be sufficient for my 
>> purposes.
>> I have started building my controlfile upon the classroom exercise #2 
>> (rtcalc)  included in the release package, so if you could show me how to 
>> include FASTEM into that example, that would be just great.
>> Please let me know if you need more info about the planned usage to give me 
>> a hint on this.
>> Thank you for your help,
>> Natalia
>> Natalia Bliankinshtein
>> Research Council Officer/Agent du Conseil de recherches
>> NRC Aerospace/CNRC Aérospatiale
>> National Research Council Canada/Conceil National de recherches Canada
>> 1200 Montreal Rd, Ottawa (Ontario)  K1A 0R6
>> Bldg/Edifice U-61 | Rm/Ch. 233A
>> 1920 Research Private
>> Tel.: (613) 998-5349 | Cellphone: (343) 549-4262
>> natalia.bliankinsht...@nrc-cnrc.gc.ca
>> 
>> From: Patrick Eriksson 
>> Sent: March 7, 2019 2:43 AM
>> To: Bliankinshtein, Natalia; arts_users.mi@lists.uni-hamburg.de
>> Subject: Re: [arts-users] FASTEM in ARTS
>> Dear Natalia,
>> Yes, FASTEM is at hand, but it is a bit tricky to give a general answer.
>> It depends on e.g.
>> * Do you want to retrieve any surface properties?
>> * Do you want to set specific wind speeds etc, or do you want to obtain
>> wind speed etc. by interpolation from some data?
>> Can you give us some more information?
>> Bye,
>> Patrick
>> On 2019-03-06 20:51, Bliankinshtein, Natalia wrote:
>>> Dear ARTS users and developers,
>>> 
>>> 
>>> I have recently started learning ARTS and appreciate its extreme
>>> flexibility.
>>> 
>>> According to the documentation, ARTS does not include an option of using
>>> FASTEM6 water surface model, however I see some evidence people have
>>> used it, for example here in Mr. Oliver Lemke's repository
>>> https://github.com/olemke/arts/tree/master/3rdparty/fastem and in Mr.
>>> Stuart Fox's email to the list in November 2018.
>>> 
>>> 
>>> I am struggling though to come up with a controlfile that would call
>>> FASTEM6. So I am kindly asking if anyone could please share a minimum
>>> working example of how to do that?
>>> 
>>> 
>>> Also, a workaround that could work for my purposes would be reading
>>> surface reflectivities from a file, which I tried. It seems to me,
>>> however, that surface emissivities are always computed as
>>> (1-reflectivity), which is not the case for FASTEM. Thus my question: is
>>> it possible to override surface emissivity and to read it from a file
>>> instead?
>>> 
>>> 
>>> Looking forward to hear your valuable advice.
>>> 
>>> 
>>> Best regards,
>>> 
>>> Natalia
>>> 
>>> 
>>> 
>>> *Natalia Bliankinshtein*
>>> 
>>> Research Council Officer/Agent du Conseil de recherches
>>> NRC Aerospace/CNRC Aérospatiale
>>> National Research Council Canada/Conceil National de recherches Canada
>>> 1200 Montreal Rd, Ottawa (Ontario)  K1A 0R6
>>> Bldg/Edifice U-61 | Rm/Ch. 233A
>>> 1920 Research Private
>>> Tel.: (613) 998-5349 | Cellphone: (343) 549-4262
>>> 

Re: [arts-users] basics of ATRS

[Oliver Lemke]

Hi Sisma,

> On 5 Mar 2019, at 18:25, Sisma Samuel  wrote:
> 
> sir,
> Thank you, I am a beginner i don't know how to compile .arts file. can you 
> please  explain how to run a sample program,  for any example in classroom 
> exercise of control files.

Start by adding the arts/build/src directory to your search path variable. This 
way you can call the arts executable from anywhere without having to give the 
whole path. Starting from the toplevel ARTS directory, use this command to set 
the PATH and test if it worked:

export PATH=$PWD/build/src:$PATH
arts -v

Now you can call ARTS with a controlfile. Try to run the TestClearSky:

cd controlfiles/artscomponents/clearsky
arts -r020 TestClearSky.arts

You should see some log output and the message 'Everything seems fine. 
Goodbye.'.

For the classroom examples, you also need the arts-xml-data package, which you 
can download here:

http://www.radiativetransfer.org/misc/download/stable/2.2/arts-xml-data-2.2.5.tar.gz

When running a classroom example, you need to tell arts where it can find the 
arts-xml-data package. Assuming you have unpacked it in your home directory, 
the command for controlfiles/classroom_exercises/exe1_absorption/ would look 
like this:

cd controlfiles/artscomponents/clearsky
arts -r020 -D$HOME/arts-xml-data-2.2.5 absorption.arts

If you have arts-xml-data unpacked elsewhere, adapt the -D argument accordingly.

Hope this helps,
Oliver


> I know IDL language, no one in my institute is currently using ARTS that is 
> the reason why I am asking very basic questions. 
> 
> On Tue, Mar 5, 2019 at 3:56 PM Oliver Lemke  
> wrote:
> Hi Sisma,
> 
> > On 5 Mar 2019, at 11:02, Sisma Samuel  wrote:
> > 
> > sir,
> > I am a  degree student, I wish to learn ARTS, can any one suggest me few 
> > simple tutorials and user guides to start on.
> 
> You can find user guides and articles about the features on the ARTS homepage 
> at:
> 
> http://www.radiativetransfer.org/docs/
> 
> The ARTS source distribution contains a lot of example controlfiles that can 
> help you to get started. For example, 
> arts/controlfiles/artscomponents/clearsky/TestClearSky.arts shows how to do 
> clearsky calculations in a 1D, 2D or 3D atmospheres.
> 
> > I installed arts by following the guidelines in ARTS website and 
> > Features in this build: 
> >Numeric precision:double
> >OpenMP support:   enabled
> >Documentation server: enabled
> >Zipped XML support:   enabled
> >NetCDF support:   disabled
> >Fortran support:  disabled
> >Disort support:   disabled
> >Refice support:   disabled
> >Tmatrix support:  disabled
> > Why certain features are not enabled  can any one help me and please give 
> > me valuable suggestions
> 
> The features that need Fortran are disabled by default. The source 
> distribution contains a README file that describes how to enable them in the 
> "OPTIONAL FEATURES" section. Depending on what you wanna do with ARTS you 
> might not even need them.
> 
> Cheers,
> Oliver
> 
> 
> 
> -- 
> Yours faithfully
> Sisma Samuel.



smime.p7s
Description: S/MIME cryptographic signature
___
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] basics of ATRS

[Oliver Lemke]

Hi Sisma,

> On 5 Mar 2019, at 11:02, Sisma Samuel  wrote:
> 
> sir,
> I am a  degree student, I wish to learn ARTS, can any one suggest me few 
> simple tutorials and user guides to start on.

You can find user guides and articles about the features on the ARTS homepage 
at:

http://www.radiativetransfer.org/docs/

The ARTS source distribution contains a lot of example controlfiles that can 
help you to get started. For example, 
arts/controlfiles/artscomponents/clearsky/TestClearSky.arts shows how to do 
clearsky calculations in a 1D, 2D or 3D atmospheres.

> I installed arts by following the guidelines in ARTS website and 
> Features in this build: 
>Numeric precision:double
>OpenMP support:   enabled
>Documentation server: enabled
>Zipped XML support:   enabled
>NetCDF support:   disabled
>Fortran support:  disabled
>Disort support:   disabled
>Refice support:   disabled
>Tmatrix support:  disabled
> Why certain features are not enabled  can any one help me and please give me 
> valuable suggestions

The features that need Fortran are disabled by default. The source distribution 
contains a README file that describes how to enable them in the "OPTIONAL 
FEATURES" section. Depending on what you wanna do with ARTS you might not even 
need them.

Cheers,
Oliver



smime.p7s
Description: S/MIME cryptographic signature
___
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] On the changes around iy-methods

[Oliver Lemke]

Hi Victoria,

Based on the small extract of your controlfile, it seems you're calling 
iyEmissionStandard directly? Not sure that's gonna work because 
iyEmissionStandard is supposed to be called only through the iy_main_agenda 
which is executed by yCalc. yCalc then takes care of the initialization of 
diy_dx.

However, you can try to do a fake initialization of diy_dx by putting 
'Touch(diy_dx)' before your iyEmissionStandard call.

Cheers,
Oliver


> On 18 Dec 2018, at 18:30, Victoria Sol Galligani 
>  wrote:
> 
> Hi! I'm updating old codes to use the latest version of arts and I am having 
> some trouble. I'm trying to retrieve pressure, temperature, and other 
> variables along the ppath. I am trying to use iyEmissionStandard the 
> following way: 
> 
> Copy(iy_main_agenda, iy_main_agenda__Emission)
> 
> IndexSet(iy_agenda_call1, 1)
> Tensor3SetConstant( iy_transmission, 0, 0, 0, 0.0 )
> 
> ppathCalc
> 
> iyEmissionStandard( iy, iy_aux, diy_dx, ppvar_p, ppvar_t, ppvar_nlte, 
> ppvar_vmr,   ppvar_wind,
> ppvar_mag, ppvar_f, ppvar_iy,
> ppvar_trans_cumulat, ppvar_trans_partial, iy_id,
> stokes_dim, f_grid, atmosphere_dim, p_grid,
> z_field, t_field, nlte_field, vmr_field,
> abs_species, wind_u_field, wind_v_field,
> wind_w_field, mag_u_field, mag_v_field,
> mag_w_field, cloudbox_on, iy_unit, iy_aux_vars,
> jacobian_do, jacobian_quantities, ppath,
> rte_pos2, propmat_clearsky_agenda,
> water_p_eq_agenda, iy_main_agenda,
> iy_space_agenda, iy_surface_agenda,
> iy_cloudbox_agenda, iy_agenda_call1,
> iy_transmission, rte_alonglos_v,
> surface_props_data )
> 
> 
> and I can't seem to be able to ignore diy_dx
> 
> What is the correct way to retrieve for example ppvar_p, ppvar_t and ppvar_vmr
> 
> Thank you in advance!!! 
> 
> Victoria
> 
> 
> 
> 
> 
> ___
> 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

Re: [arts-users] Is this a bug in ARTS

[Oliver Lemke]

Hi Alfred,

The "Rng_seed" is just a name that identifies the critical region. The pragma 
ensures that only one thread at a time enters critical regions with the same 
name. I don't see how that change could have any effect on your error.

Cheers,
Oliver


> On 26 Oct 2018, at 07:02, Alfred Xu  wrote:
> 
> Hello,everyone.
> when i used open-mp for ARTS, an error occurred because of error use of 
> vector. I traced the problem and found that Rng_seed has no definition.
> I changed Rng_seed to seeds (see code below)and got it work. So, I'd like to 
> know is this a bug in ARTS.
> 
> Thank you!
> Alfred xu
> 
> /*!
>  Seeds the Rng with the integer argument. 
> 
>  Every seed is only used once. The provided seed is increased by 1 until an
>  unused seed is found.
> */
> void Rng::seed(unsigned long int n, const Verbosity& verbosity)
> {
>   // Static pool of previously used seeds.
>   static vector seeds;
> 
> #pragma omp critical (Rng_seed)
>   {
> unsigned long int n_orig = n;
> //cout << "Requested seed: " << n;
> while (find(seeds.begin(), seeds.end(), n) != seeds.end())
> {
>   if (n >= ULONG_MAX - 1)
> n=0;
>   else
> n++;
>   
>   // If all possible seeds were already used, we empty the pool and
>   // start over.
>   if (n == n_orig)
>   {
> CREATE_OUT0;
> out0 << "Rng Warning: Couldn't find an unused seed. Clearing seed 
> pool.\n";
> seeds.empty();
> break;
>   }
> }
> seeds.push_back(n);
> seed_no=n;
> //cout << " Got seed: " << seed_no << endl;
>   }
>   
>   gsl_rng_set(r,seed_no);
> }
> ___
> 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

Re: [arts-users] Problems encountered in ARTS installation

[Oliver Lemke]

Dear 董杉彬,

Which exact ARTS version are you using?

I assume the linker error about gzread, gzopen, gzclose and gzwrite says 
something like "Unresolved symbol? Sorry, my Chinese is a bit rusty. ;-)

As the error appears with a test_* target, which is only needed for internal 
testing, please try to only compile the arts executable and see if the same 
error occurs (which I expect, but let's give it a try anyway):

make arts

or even:

LC_ALL=C make arts

The second command should give error messages in English. :-)

The error in your attached CMakeError.log file about no-return-type-c-linkage 
can be ignored. This is only a test to see if the compiler supports it. It's 
only needed for older compiler versions.

I don't really have a clue yet why you get the linker errors you're seeing. To 
further diagnose the issue please send me the following:


1) The full cmake commandline including all the options you passed to it.

2) Your PATH variable, to see if anything potentially causing issues:

echo $PATH

3) The output of the following command to double check that the dependency 
libraries are correctly installed:

dpkg -l zlib1g-dev libnetcdf-dev liblapack-dev libblas-dev


Hopefully these will help us to the bottom of the issue.

Cheers,
Oliver


> On 17 Oct 2018, at 16:20, 董杉彬 <773820...@qq.com> wrote:
> 
> Dear Mr/Mrs：
>   I am a student who study in Wuhan,China,When I install the ARTS 
> software,there are some bugs appearing.Here are the log files in the appendix.
> My computer operating system is ubuntu 18.04,I have already install the ZLIB 
> and NETCDF completely.The fortran compiler and gcc compiler is version 7.
>   I am looking forward to your early reply!
> <92393...@d57d0b65.3345c75b.png.jpg>
> <92393...@d57d0b65.3345c75b.png.jpg>___
> 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

Re: [arts-users] ARTS OEM

[Oliver Lemke]

Hi Byungsuk,

> On 17 Oct 2018, at 10:54, Byungsuk Lee  wrote:
> 
> Hello Oliver,
> 
> Thank you for your reply. 
> 
> I have tried with AppleClang without OpenMP, and the installation was 
> successfully completed. Thank you. 
> 
> With that, I tried my OEM code, but the irregular t_field errors (discussed 
> previously in emails with ARTS users and Simon Pfreundschuh) still occurred. 
> 
> I have tried with Homebrew Clang or GCC compilers and without the fortran and 
> netCDF supports as well, and the errors still persisted. 
> 
> I am starting to question that the externally installed compilers or the 
> packages might not be the problem. Maybe it has something more to do with 
> some fundamental or built-in feature of Mac that is different from Ubuntu. 
> What it may actually be, I could not guess.  

Yes, looking at the "consistency" of the results, I totally agree with you.

> If anyone has tried the development version's OEM on Mac (or Macbook), with 
> the test file "ARTS/controlfiles/artscomponents/oem/TestOEM.arts", with the 
> retrieval quantity switched from O3 vmr to temperature, with the number of 
> frequencies and the number of pressure layers reduced to about 20 (f_grid, 
> p_gird, and p_ret_grid), and was successful without irregularly occurring 
> errors for t_field during OEM, please let me know.  

I'm developing on Mac myself and can take a closer look at it. But can you 
please mail me the controlfile which exhibits this behaviour? I want to be 100% 
sure I'm running the same as you and don't want to dig through the whole mail 
thread piecing together the bits of information about the exact setup. :-)

Cheers,
Oliver

___
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] ARTS OEM

[Oliver Lemke]

Hi Byungsuk,

> On 8 Oct 2018, at 07:26, Byungsuk Lee  wrote:
> 
> Hello Oliver,
> 
> Thank you for your reply.
> 
> 1) I don't think there is any Intel-related library in my PATH. Could any of 
> them below be an Intel library? Below are some of the lines from 
> CMakeCache.txt after cmake command using Apple Clang v10 and GNU gfortran 
> v8.2.0:
> [snip]
> //Details about finding OpenMP
> FIND_PACKAGE_MESSAGE_DETAILS_OpenMP:INTERNAL=[TRUE][TRUE][TRUE][c ][v3.1()]
> //Details about finding OpenMP_C
> FIND_PACKAGE_MESSAGE_DETAILS_OpenMP_C:INTERNAL=[-Xclang 
> -fopenmp][/usr/local/lib/libomp.dylib][v3.1()]
> //Details about finding OpenMP_CXX
> FIND_PACKAGE_MESSAGE_DETAILS_OpenMP_CXX:INTERNAL=[-Xclang 
> -fopenmp][/usr/local/lib/libomp.dylib][v3.1()]
> //Details about finding OpenMP_Fortran
> FIND_PACKAGE_MESSAGE_DETAILS_OpenMP_Fortran:INTERNAL=[-fopenmp][/usr/local/Cellar/gcc/8.2.0/lib/gcc/8/libgomp.dylib][v4.5()]
> [snip]

Doesn't look like any Intel related libraries are present. I guess 
/usr/local/lib/libomp.dylib comes from brew? You could try to do a compilation 
without the Fortran, NetCDF and OpenMP features. I don't think you need any of 
the Fortran modules for your calculation. You can disable OpenMP with 'cmake 
-DNO_OPENMP=1 ..'. Just to see if that fixes the compilation errors.

> 2) After installing ARTS with Homebrew llvm clang/clang++: 
> export CC=/usr/local/opt/llvm/bin/clang
> export CXX=/usr/local/opt/llvm/bin/clang++
> export FC=/usr/local/opt/gcc/bin/gfortran
> cmake -DENABLE_C_API=1 
> -DARTS_XML_DATA_PATH=/Users/BLee/Desktop/ARTS/arts-xml-data-dev 
> -DENABLE_FORTRAN=1 -DENABLE_NETCDF=1 ..
> make -j4
> 
> I get the following from typing "otool -L src/arts":
> src/arts:
>   /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
> 1.2.11)
>   /usr/local/opt/netcdf/lib/libnetcdf.13.dylib (compatibility version 
> 13.0.0, current version 13.0.0)
>   /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 
> (compatibility version 1.0.0, current version 4.0.0)
>   /usr/local/opt/gcc/lib/gcc/8/libgfortran.5.dylib (compatibility version 
> 6.0.0, current version 6.0.0)
>   /usr/local/lib/gcc/8/libgcc_s.1.dylib (compatibility version 1.0.0, 
> current version 1.0.0)
>   /usr/local/opt/gcc/lib/gcc/8/libquadmath.0.dylib (compatibility version 
> 1.0.0, current version 1.0.0)
>   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
> version 1252.50.4)
>   /usr/local/opt/libomp/lib/libomp.dylib (compatibility version 5.0.0, 
> current version 5.0.0)
>   /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
> 400.9.0)
> 
> I am guessing that the Accelerate framework is properly included? 

Yes, that looks correct.

Cheers,
Oliver


> Thank you,
> 
> Byungsuk Lee
> 
>  
> 
> On Thu, Oct 4, 2018 at 5:49 PM Oliver Lemke  
> wrote:
> Hi Byungsuk,
> 
> > On 2 Oct 2018, at 11:39, Byungsuk Lee  wrote:
> > 
> > Dear Jonas and Oliver,
> > 
> > Thank you for your replies. I wanted to give you a sort of status report 
> > regarding the use of ARTS on my Mac. 
> > 
> > 1) I checked ARTS/build/CMakeCache.txt and confirmed that no conda package 
> > was used, other than CONDA_PROG:FILEPATH=... which I think is irrelevant. 
> > 
> > 2) I tried compiling with gcc/g++ instead, both from Homebrew and from 
> > manually installing tar.gz files from the gnu website for a few different 
> > versions, but the same irregular invalid t_field errors in OEM happened. 
> > Plus, at the cmake stage, they constantly produced a failure message for 
> > "Wno-return-type-c-linkage" as follows, about which I am curious why. This 
> > doesn't happen with clang/clang++. 
> > 
> > ...
> > -- Performing Test CCFLAG_Wno-sign-conversion
> > -- Performing Test CCFLAG_Wno-sign-conversion - Success
> > -- Performing Test CXXFLAG_Wno-sign-conversion
> > -- Performing Test CXXFLAG_Wno-sign-conversion - Success
> > -- Performing Test CCFLAG_Wno-unknown-pragmas
> > -- Performing Test CCFLAG_Wno-unknown-pragmas - Success
> > -- Performing Test CXXFLAG_Wno-unknown-pragmas
> > -- Performing Test CXXFLAG_Wno-unknown-pragmas - Success
> > -- Performing Test CCFLAG_Wno-return-type-c-linkage
> > -- Performing Test CCFLAG_Wno-return-type-c-linkage - Failed
> > -- Performing Test CXXFLAG_Wno-return-type-c-linkage
> > -- Performing Test CXXFLAG_Wno-return-type-c-linkage - Failed
> > -- Performing Test CCFLAG_Wno-strict-overflow
> > -- Performing Test CCFLAG_Wno-strict-overflow - Success
> > -- Performing Test CXXFLAG_Wno-strict-overflow
> > 

Re: [arts-users] ARTS OEM

[Oliver Lemke]

Hi Byungsuk,

> On 2 Oct 2018, at 11:39, Byungsuk Lee  wrote:
> 
> Dear Jonas and Oliver,
> 
> Thank you for your replies. I wanted to give you a sort of status report 
> regarding the use of ARTS on my Mac. 
> 
> 1) I checked ARTS/build/CMakeCache.txt and confirmed that no conda package 
> was used, other than CONDA_PROG:FILEPATH=... which I think is irrelevant. 
> 
> 2) I tried compiling with gcc/g++ instead, both from Homebrew and from 
> manually installing tar.gz files from the gnu website for a few different 
> versions, but the same irregular invalid t_field errors in OEM happened. 
> Plus, at the cmake stage, they constantly produced a failure message for 
> "Wno-return-type-c-linkage" as follows, about which I am curious why. This 
> doesn't happen with clang/clang++. 
> 
> ...
> -- Performing Test CCFLAG_Wno-sign-conversion
> -- Performing Test CCFLAG_Wno-sign-conversion - Success
> -- Performing Test CXXFLAG_Wno-sign-conversion
> -- Performing Test CXXFLAG_Wno-sign-conversion - Success
> -- Performing Test CCFLAG_Wno-unknown-pragmas
> -- Performing Test CCFLAG_Wno-unknown-pragmas - Success
> -- Performing Test CXXFLAG_Wno-unknown-pragmas
> -- Performing Test CXXFLAG_Wno-unknown-pragmas - Success
> -- Performing Test CCFLAG_Wno-return-type-c-linkage
> -- Performing Test CCFLAG_Wno-return-type-c-linkage - Failed
> -- Performing Test CXXFLAG_Wno-return-type-c-linkage
> -- Performing Test CXXFLAG_Wno-return-type-c-linkage - Failed
> -- Performing Test CCFLAG_Wno-strict-overflow
> -- Performing Test CCFLAG_Wno-strict-overflow - Success
> -- Performing Test CXXFLAG_Wno-strict-overflow
> -- Performing Test CXXFLAG_Wno-strict-overflow - Success
> ...

Some compilers don't support the flag no-return-type-c-linkage. That is totally 
fine and the reason that we test its existence with cmake before enabling it.

> 3) Instead of the clang/clang++ from Homebrew llvm with which I initially 
> installed ARTS, I thought I could instead try using Mac's command line tools 
> clang/clang++ (AppleClang v10), but they failed at the make stage with the 
> following error which I am not sure how to tackle.  
> 
> ...
> [ 43%] Linking CXX executable make_auto_workspace_h
> Undefined symbols for architecture x86_64:
>   "___kmpc_critical", referenced from:
>   ArtsOut& operator<< std::__1::char_traits, std::__1::allocator > >(ArtsOut&, 
> std::__1::basic_string, 
> std::__1::allocator > const&) in arts.cc.o
>   ArtsOut& operator<<(ArtsOut&, char const (&) [35]) in 
> file.cc.o
>   ArtsOut& operator<<(ArtsOut&, char const (&) [75]) in 
> file.cc.o
>   ArtsOut& operator<<(ArtsOut&, char const (&) [2]) in file.cc.o
>   ArtsOut& operator<< >(ArtsOut&, 
> my_basic_string const&) in file.cc.o
>   ArtsOut& operator<<(ArtsOut&, char const (&) [3]) in file.cc.o
>   ArtsOut& operator<<(ArtsOut&, long const&) in file.cc.o
>   ...
>   "___kmpc_end_critical", referenced from:
>   ArtsOut& operator<< std::__1::char_traits, std::__1::allocator > >(ArtsOut&, 
> std::__1::basic_string, 
> std::__1::allocator > const&) in arts.cc.o
>   ArtsOut& operator<<(ArtsOut&, char const (&) [35]) in 
> file.cc.o
>   ArtsOut& operator<<(ArtsOut&, char const (&) [75]) in 
> file.cc.o
>   ArtsOut& operator<<(ArtsOut&, char const (&) [2]) in file.cc.o
>   ArtsOut& operator<< >(ArtsOut&, 
> my_basic_string const&) in file.cc.o
>   ArtsOut& operator<<(ArtsOut&, char const (&) [3]) in file.cc.o
>   ArtsOut& operator<<(ArtsOut&, long const&) in file.cc.o
>   ...
>   "___kmpc_global_thread_num", referenced from:
>   ArtsOut& operator<< std::__1::char_traits, std::__1::allocator > >(ArtsOut&, 
> std::__1::basic_string, 
> std::__1::allocator > const&) in arts.cc.o
>   ArtsOut& operator<<(ArtsOut&, char const (&) [35]) in 
> file.cc.o
>   ArtsOut& operator<<(ArtsOut&, char const (&) [75]) in 
> file.cc.o
>   ArtsOut& operator<<(ArtsOut&, char const (&) [2]) in file.cc.o
>   ArtsOut& operator<< >(ArtsOut&, 
> my_basic_string const&) in file.cc.o
>   ArtsOut& operator<<(ArtsOut&, char const (&) [3]) in file.cc.o
>   ArtsOut& operator<<(ArtsOut&, long const&) in file.cc.o
>   ...
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> make[2]: *** [src/make_auto_workspace_h] Error 1
> make[1]: *** [src/CMakeFiles/make_auto_workspace_h.dir/all] Error 2
> [ 43%] Building CXX object 
> src/CMakeFiles/test_gridded_fields.dir/test_gridded_fields.cc.o
> [ 43%] Building CXX object src/CMakeFiles/test_legendre.dir/test_legendre.cc.o
> [ 43%] Linking CXX executable test_legendre
> [ 43%] Built target test_legendre
> [ 43%] Linking CXX executable test_gridded_fields
> [ 43%] Built target test_gridded_fields
> make: *** [all] Error 2
> ...

This is interesting. The __kmpc_* Symbols come from the Intel Math Kernel 
Library. These errors usually indicate that the Intel Threading library was 
enabled, 

Re: [arts-users] ARTS OEM

[Oliver Lemke]

Hi Jonas, hi Byungsuk Lee,

We had similar issues, but more in the opposite direction. When we compiled 
ARTS with the anaconda environment activated, we ran into issues later when 
executing ARTS. Therefore, ARTS in its default configuration automatically 
ignores conda paths that are detected when cmake is run. To disable this, you 
need to pass '-DENABLE_ALLPATHS=1' to cmake.

Since this only happens on certain configurations, we haven't been able to 
fully identify the source of this problem.

@byungsuk: Another test you could do is to use a different compiler. Since 
you're using gfortran 8.2.0, I assume that you also have gcc/g++ installed. You 
could try to compile with them instead of clang by setting them with the cmake 
options, e.g. "cmake -DCMAKE_C_COMPILER=/usr/local/bin/gcc 
-DCMAKE_CXX_COMPILER=/usr/local/bin/g++ ...'. Note that changing compilers 
requires to delete everything in your build directory, a 'make clean' is not 
enough.

cheers,
/oliver


> On 27 Sep 2018, at 11:57, Jonas Hagen  wrote:
> 
> Hi Byungsuk Lee
> 
> From your pasted output, I can guess that you are using conda on your ubuntu 
> machine. I had similar problems (strange crashes) when using ARTS within a 
> conda environment.
> 
> Conda / Anaconda does not only manage python stuff, but also many compiled 
> libraries.
> The solution is to compile ARTS in the environment that you wish to use for 
> execution. If you run ARTS within a Conda environment (possibly via the API), 
> then you must activate this environment also for compilation. In the other 
> case, if you want to run ARTS without conda environment, then make sure 
> nothing from Conda is used for linking. To do that, maybe updating conda can 
> help, because the newer versions make a much better separation of your system 
> libraries and managed ones. Also removing all conda related commands from 
> your bashrc (and reboot) could help.
> 
> That would be my guess.
> Best regards,
> Jonas
> 
> On 27.09.2018 10:22, Byungsuk Lee wrote:
>> Dear Simon,
>> 
>> Yes, I have sent the exact code.  
>> 
>> I have tried the code in two different computers: one is Mac and another 
>> Ubuntu. The problem still occurs on my Mac but not on my Ubuntu. Could it be 
>> due to the differences in the ARTS' configurations? Below are the output 
>> lines for the cmake command "cmake -DENABLE_C_API=1 
>> -DARTS_XML_DATA_PATH=/path/to/xml-data/ -DENABLE_FORTRAN=1 -DENABLE_NETCDF=1 
>> .." in the build directory. I am using the older version (have not updated 
>> to include the recent changes for freq shift retrieval).
>> 
>> 
>> 
>> For Mac:
>> -- The C compiler identification is Clang 7.0.0
>> -- The CXX compiler identification is Clang 7.0.0
>> -- Check for working C compiler: /usr/local/opt/llvm/bin/clang
>> -- Check for working C compiler: /usr/local/opt/llvm/bin/clang -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Detecting C compile features
>> -- Detecting C compile features - done
>> -- Check for working CXX compiler: /usr/local/opt/llvm/bin/clang++
>> -- Check for working CXX compiler: /usr/local/opt/llvm/bin/clang++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Detecting CXX compile features
>> -- Detecting CXX compile features - done
>> -- The Fortran compiler identification is GNU 8.2.0
>> -- Checking whether Fortran compiler has -isysroot
>> -- Checking whether Fortran compiler has -isysroot - yes
>> -- Checking whether Fortran compiler supports OSX deployment target flag
>> -- Checking whether Fortran compiler supports OSX deployment target flag - 
>> yes
>> -- Check for working Fortran compiler: /usr/local/bin/gfortran
>> -- Check for working Fortran compiler: /usr/local/bin/gfortran  -- works
>> -- Detecting Fortran compiler ABI info
>> -- Detecting Fortran compiler ABI info - done
>> -- Checking whether /usr/local/bin/gfortran supports Fortran 90
>> -- Checking whether /usr/local/bin/gfortran supports Fortran 90 -- yes
>> -- Looking for sys/types.h
>> -- Looking for sys/types.h - found
>> -- Looking for stdint.h
>> -- Looking for stdint.h - found
>> -- Looking for stddef.h
>> -- Looking for stddef.h - found
>> -- Check size of long
>> -- Check size of long - done
>> -- Looking for stdlib.h
>> -- Looking for stdlib.h - found
>> -- Looking for string.h
>> -- Looking for string.h - found
>> -- Looking for strings.h
>> -- Looking for strings.h - found
>> -- Looking for sys/stat.h
>> -- Looking for sys/stat.h - found
>> -- Looking for sys/times.h
>> -- Looking for sys/times.h - found
>> -- Looking for unistd.h
>> -- Looking for unistd.h - found
>> -- Looking for getopt.h
>> -- Looking for getopt.h - found
>> -- Looking for pthread.h
>> -- Looking for pthread.h - found
>> -- Looking for pthread_create
>> -- Looking for pthread_create - found
>> -- Found Threads: TRUE  
>> -- Looking for fcntl.h
>> -- Looking for fcntl.h - found
>> -- Looking for math.h
>> -- Looking for 

Re: [arts-users] How to get "libarts_api.so" in my ARTS_BUILD_PATH?

[Oliver Lemke]

Hi Reno,

Looks like you're using either the stable ARTS release (the API is a dev 
feature) or your development version is not updated.

You can checkout the latest development version from svn with:

svn co https://arts.mi.uni-hamburg.de/svn/rt/arts/trunk/ arts

Be aware that if you're currently using the stable version that some adaption 
of controlfiles is necessary.

Cheers,
Oliver


> On 12 Mar 2018, at 14:48, Reno Choi  wrote:
> 
> Hello,
> 
> While pretty new to Arts (and Typhon), let alone python, I'm trying to figure 
> out tools available around Arts.
> 
> Upon configuring Typhon, it looks like asking "libarts_api.so" in my 
> ARTS_BUILD_PATH, from 
> "/Users/reno/anaconda3/lib/python3.6/site-packages/typhon/arts/workspace/api.py"
>  (line 52).
> 
> An attempt to use "-DENABLE_C_API=1" with CMAKE for Arts compiling, ended up 
> with the following message,
> 
> CMake Warning:
>   Manually-specified variables were not used by the project:
> 
> ENABLE_C_API 
> 
> Although (I believe) Arts is fully functional with all features are enabled, 
> it seems not to be ready for Typhon.
> 
> How can I get "libarts_api.so" during Arts compile?
> 
> 
> -- 
> Dr. Reno K.-Y. Choi
> 
> T. (+44 0)1225 719 478
> T. (+44 0)20 8133 9066
> T. (+82 0)70 7893 2756
> M. (+44 0)7909 612 846
> M. (+82 0)10 4570 9066
> ___
> 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

Re: [arts-users] HITRAN2012.par

[Oliver Lemke]

Hi Andrey,

> On 19 Sep 2017, at 15:16, Dr. Andrey P.Chernushich  
> wrote:
> 
> One more question. In which directory the abs_linesReadFromHitran function 
> search for file HITRAN2012.par if called as it shown in a sample olr.arts?

If you give a relative path, it searches in the current working directory and 
every path in the ARTS data search path. The data search path can be either be 
specified by listing directories with the 'arts -D' option or by setting the 
environment variable ARTS_DATA_PATH.

You can see the current search path by calling arts with the -v option.

cheers,
/oliver

___
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] Newbie question - help me with XML files output

[Oliver Lemke]

Hi Andrey,

> On 1 Aug 2017, at 16:12, Dr. Andrey P.Chernushich  
> wrote:
> 
> Thank you, Oliver!
> 
> I can't understand how can I answer in the same branch of the mailing list?

Just make sure that the mailing list address is in the 'To:' or 'Cc:' field, 
either by using 'reply-all' in your mail tool or adding it manually. In the 
archive it'll be automatically sorted into the right branch by subject.

> And as a reply to your answer, can not I to join by some way several 
> variables (for example - same variables: p_field and t_field) in one complex 
> variable to output them in one xml file?

It is possible to combine variables of the same type (workspace group) into an 
array. If you have two Tensor3 variables, then you can do the following:

Arts2{
# Init two tensor3 variable with dummy values
Tensor3SetConstant(t_field, 2, 2, 2, 279)
Tensor3SetConstant(z_field, 3, 3, 3, 100)

ArrayOfTensor3Create(combined_vars)

Append(combined_vars, t_field)
Append(combined_vars, z_field)
WriteXML("ascii", combined_vars, "combined.xml")
Delete(combined_vars)
}

Where do you see the variable p_field? I'm not aware of any ARTS variable by 
that name.

cheers,
/oliver

___
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] Running ARTS using cygwin under windows

[Oliver Lemke]

Hi Giovanni,

For the include issue, you can try setting the include path explicitly with the 
-I option when running arts:

$ arts -I 'f:\temp\' -v

arts-2.3.654 (compiled Wed Mar 22 14:09:51 2017)
Compiler: Clang 8.0.0.842
[snip]
Include search paths: 
   .
   f:\temp\
Data search paths: 
   .

The problem with cygwin is that it creates a very schizophrenic environment 
when it comes to paths. While you're inside the cygwin shell, programs see a 
'virtual' Unix-like filesystem with / as a directory separator and your home 
directory at /home, system programs in /usr etc. This is why the default 
include path looks like it does in your case. It is determined at compile time 
while being inside the Unix-world. When calling cygwin-compiled programs from 
outside the cygwin shell, e.g. from Matlab, suddenly everything changes and the 
program is exposed to the normal windows filesystem.

I don't see a good way of handling this. My guess is that cygwin programs are 
not even supposed to be called outside their natural habitat (i.e. the cygwin 
shell).

Let's see if the -I option helps you out here.

cheers,
/oliver


> On 6 Apr 2017, at 17:10, Giovanni Muscari  wrote:
> 
> Dear all,
> 
> so far I've used arts 2.0 by compiling/making it using cygwin and then 
> running it in a windows environment, making use of scripts contained in 
> atmlab 2.0.0. It works smoothly.
> 
> I am now trying to do the same with arts 2.2 and atmlab 2.2.22 but run into 
> issues that seem to be related to search paths for the cfile.rep or include 
> files.
> 
> As an example, after making the arts.exe in cygwin I tried to run the 
> qarts_demo (providing all the correct paths for includes and such) and this 
> is what I get:  
> 
> -
> >> qarts_demo
> Cannot open output file: 
> f:\ARTS\tmp\atmlab-GM-tp1daee2b5_03ac_4fb8_94c0_fa0a67f557b6/f:\ARTS\tmp\atmlab-GM-tp1daee2b5_03ac_4fb8_94c0_fa0a67f557b6\cfile.rep
> Maybe you don't have write access to the directory or the file?
> I have to be able to write to my report file.
> ---
> 
> As you can see the cfile.rep file is searched in a funny path made of two 
> times the "F:\ARTS\tmp +temp_dir" separated by a "/" which is unacceptable 
> under windows. I can circumvent this problem by indicating a very simple path 
> for the temp directory (".." instead of "F:\ARTS\tmp") or by sticking my 
> hands into the main.cc source code and changing the following line:
> 
> open_output_file(report_file, out_basename + report_file_ext.str ());
> 
> However, arts goes just a little further before crashing for a search path 
> issue, when looking for include files. And I am not a C++ programmer...
> Of course the "f:\ARTS\arts-2.2\controlfiles\general\general.arts" indicated 
> below is there. 
> 
> ---
> >> qarts_demo
> Executing ARTS.
> Command line:
> /src/arts -r30 -o ..\atmlab-GM-tp2eb0677b_36b0_4a15_8728_20d87c282579 
> ..\atmlab-GM-tp2eb0677b_36b0_4a15_8728_20d87c282579\cfile.arts 
> Version: arts-2.2.55 (compiled Thu Apr  6 15:27:51 2017)
> Compiler: GNU 5.4.0 (/usr/bin/c++.exe)
> Compile flags:  -fvisibility=hidden -fvisibility-inlines-hidden 
> -ftemplate-depth-60 -fopenmp  -W  -Wall  -Wshadow  -Wconversion  
> -Wno-sign-conversion  -Wno-unknown-pragmas   -O2 -g 
> Features in this build: 
>Numeric precision:double
>OpenMP support:   enabled
>Documentation server: enabled
>Zipped XML support:   enabled
>NetCDF support:   disabled
>Fortran support:  disabled
>Disort support:   disabled
>Refice support:   disabled
>Tmatrix support:  disabled
> Include search paths: 
>.
>/home/GM/controlfiles
> Data search paths: 
>..\atmlab-GM-tp2eb0677b_36b0_4a15_8728_20d87c282579
>.
> 
> Running with OpenMP, maximum number of threads = 4.
>Thread 1: ready.
>Thread 2: ready.
>Thread 0: ready.
>Thread 3: ready.
> 
> Run started: Thu Apr  6 15:46:43 2017
> 
> Verbosity settings: Agendas: 0
> Screen:  3
> Report file: 0
> 
> Reading control files:
> - ..\atmlab-GM-tp2eb0677b_36b0_4a15_8728_20d87c282579\cfile.arts
> 
> Parsing control text:
> - Arts2
> {
> This run took 0.02s (0.01s CPU time)
> Run-time error in controlfile: 
> ..\atmlab-GM-tp2eb0677b_36b0_4a15_8728_20d87c282579\cfile.arts
> Cannot find include file f:\ARTS\arts-2.2\controlfiles\general\general.arts.
> File: ..\atmlab-GM-tp2eb0677b_36b0_4a15_8728_20d87c282579\cfile.arts
> Search path was:   . /home/GM/controlfiles
> 
> Stopping ARTS execution.
> Goodbye.
> 
> Error using arts (line 67)
> An error occured while executing ARTS. See above.
> 
> 
> I understand that making 

Re: [arts-users] Examples

[Oliver Lemke]

Hi Olivier,

The SRF class is unit-aware. This means that all values you pass in, must have 
the correct unit attached. E.g.:

import typhon
typhon.physics.units.SRF([1e9] * typhon.physics.units.ureg.Hz, [1])

Unfortunately, there is currently a problem with our SRF class which makes it 
incompatible with the stable release of pint (the python module that handles 
the units). A fix for that is pending. See the discussion on the typhon.mi 
mailing list:

https://mailman.rrz.uni-hamburg.de/pipermail/typhon.mi/2017-February/42.html

You might want to hold back until we release a fixed version if you don't want 
to install the master branch of pint.

Cheers,
Oliver


> On 24 Feb 2017, at 16:23, Olivier Amram  wrote:
> 
> Hi,
>  
> I try to use the class  typhon.physics.units.SRF(f, W) but …
>  
> import numpy as np
> from typhon.physics.units import SRF
>  
> c = 299792458
> center = c / (np.arange(0.3,0.7,0.04) * 1E-6)
> weights = np.ones(len(center))
>  
> srf = SRF(center, weight)
> print(srf.blackbody_radiance(6300))
>  
> Have you an example of utilisation ?
>  
> Thanks.
>  
> Olivier
> ___
> 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

Re: [arts-users] error in disort example

[Oliver Lemke]

Hi Elisa,

>From the error message I can't say immediately what is going wrong. But the 
>development version is a quickly changing target and the snapshot version you 
>downloaded is already two months old. Probably a bad move on our part to even 
>provide snapshots of the development version in packaged format. The problem 
>might have been fixed in the meantime. If you decide to use the development 
>version, please use the svn command to check out the latest version directly 
>from the subversion repository. It will also make it much easier for you to 
>get the latest fixes.

You will need svn anyway, because we don't provide snapshots of the latest 
arts-xml-data version. You can check out the development version of 
arts-xml-data with (all in one line):

svn co https://arts.mi.uni-hamburg.de/svn/rt/arts-xml-data/trunk/ arts-xml-data

If the issue also exists in the latest revision, I'm happy to investigate what 
is going wrong.

Please also consider the implications of using a development version: A lot of 
methods have been renamed and added since the last stable version and you will 
have to adapt your existing controlfiles quite a bit. Things might continue to 
change. We of course appreciate feedback on the dev version but be ready to 
invest some time on debugging unexpected issues. :-) Ok, enough for the 
disclaimer. ;-) With all that said, the current development version is in a 
rather good shape and totally usable. All the people in the ARTS team use it 
every day for their calculations.

Cheers,
Oliver


> On 1 Sep 2016, at 14:43, 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.org/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

___
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] Advise concerning ARTS computation speed

[Oliver Lemke]

Hi Pauline,

If you didn't pass any options to cmake at the time you compiled ARTS, then you 
have an executable with debug information because that's the default.

To get a non-debug build you have to explicitly set it to release mode as 
Richard explained:

cmake -DCMAKE_BUILD_TYPE=Release ..
make clean
make

cheers,
/oliver


> On 12 Jul 2016, at 17:29, Pauline Martinet  wrote:
> 
> Hi Richard,
> 
> Thanks for your advice.
> 
> I am using the debug mode only for atmlab (the matlab interface to call ARTS).
> 
> I do not think I compiled ARTS in any debug mode. Thus, I assume it should 
> not have an impact on the ARTS speed.
> 
> Best regards,
> 
> Pauline

___
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

[Oliver Lemke]

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