Hi,
I’m trying to install pyCRTM on my linux maching. I have successfully installed CRTMv2.4.0. I’m running into a problem with the following line of code that is part of the sequence of commands executed by “python3 setup.py install”:
Since pycrtm and pycrtm.pyf are output files, I’m assuming the problem is in pycrtm.f90 or in libcrtm.a. The file libcrtm.a is of course created by the CRTM install itself. Here’s the output of the command:
Reading fortran codes…
Reading file ‘/home/dostalek/code/crtm/pycrtm/pycrtm.f90’ (format:free)
Traceback (most recent call last):
File “/home/dostalek/miniconda3/envs/pycrtm_env/bin/f2py”, line 10, in
sys.exit(main())
File “/home/dostalek/miniconda3/envs/pycrtm_env/lib/python3.9/site-packages/numpy/f2py/f2py2e.py”, line 768, in main
run_main(sys.argv[1:])
File “/home/dostalek/miniconda3/envs/pycrtm_env/lib/python3.9/site-packages/numpy/f2py/f2py2e.py”, line 463, in run_main
postlist = callcrackfortran(files, options)
File “/home/dostalek/miniconda3/envs/pycrtm_env/lib/python3.9/site-packages/numpy/f2py/f2py2e.py”, line 347, in callcrackfortran
postlist = crackfortran.crackfortran(files)
File “/home/dostalek/miniconda3/envs/pycrtm_env/lib/python3.9/site-packages/numpy/f2py/crackfortran.py”, line 3531, in crackfortran
readfortrancode(files, crackline)
File “/home/dostalek/miniconda3/envs/pycrtm_env/lib/python3.9/site-packages/numpy/f2py/crackfortran.py”, line 392, in readfortrancode
l = fin.readline()
File “/home/dostalek/miniconda3/envs/pycrtm_env/lib/python3.9/fileinput.py”, line 305, in readline
line = self._readline()
File “/home/dostalek/miniconda3/envs/pycrtm_env/lib/python3.9/fileinput.py”, line 365, in _readline
self._file = self._openhook(self._filename, self._mode)
File “/home/dostalek/miniconda3/envs/pycrtm_env/lib/python3.9/site-packages/numpy/f2py/crackfortran.py”, line 313, in openhook
encoding = charset_normalizer.from_path(filename).best().encoding
AttributeError: ‘NoneType’ object has no attribute ‘encoding’
Even though it is obvious, I will write explicitly that any help is appreciated.
Jack
That is, it does not include the reference to the CRTM library file libcrtm.a. If that is omitted, however, there is a complaint that it can’t find crtm_module for the routines wrap_forward and wrap_k_matrix, which are found in pycrtm.f90. When I include the reference to the library, the compilation finds crtm_module, but gives the original error I posted. Sorry for all of the addenda. I wouldn’t be surprised if there are more
I was correct, I do have another entry. It looks like f2py is having difficulty reading the file pycrtm.f90. I turned on f2py’s --verbose flag for the command shown in my previous post. I get many errors like this one:
Line #116 in /home/dostalek/code/crtm/pycrtm/pycrtm.f90:" sensor_id(1) = sensor_id_in "
crackline:4: No pattern for line
Also, in looking over the forum entries, it is not clear to me that anyone outside JCSDA has successfully install pyCRTM using CRTMv2.4.0. Can anyone confirm or deny that? We do have a version running using a debian container, but it does have some drawbacks, hence my desire to have a “pure” installation.
Hi @JackD.
Would you please share about what exact changes you’ve made to make the installation work?
I am having problems successfully installing the pycrtm too (even with the libcrtm.so/libcrtm.a installed from JCSDA/crtm-bundle for the v2.4.0).
Appreciate any feedback!
Hi, FYI. I would not recommend using the crtm-bundle method of installing pyCRTM. It is hardwired to an outdated version. I have a branch that is yet to be committed the the pyCRTM repository that has a much cleaner solution. GitHub - JCSDA/pycrtm at feature/prepCRTMv3. There is a script “make_it_so.sh” that it similar to the kickstart script, but uses CRTMv3. If you desire CRTM 2.4, you can point/build to a CRTM 2.4 install instead as it is backward compatible.
Thank you both, @JackD and @karpob, for the feedback.
I tried both of your suggestions, but unfortunately the same error persists:
It broke at building the pycrtm complaining: appenddecl: “dimension” not implemented.
I thought it was something related to the version of the CRTM module I used for the installation.
But looks like it’s not, given that same error occurs for the CRTMv3 with karpob’s approach.
Could you please send me the full list of commands and errors you’re seeing? There are many red herrings with compilation, and things are not always what they seem.
Also, what distribution of linux are you using, and are you switching to a specified conda environment or are you using system libraries? If you have both and are not careful, this can lead to many problems.
Your later post is ringing a bell: I do have a self-installed conda environment activated (through the .bashrc everytime logging on the machine) while I have been trying to install the pycrtm with loaded system libraries:
Could you please provide some instructions regarding how to neatly take either approach?
I attached the installation print-out (the log file) for the installation command: pip install . --user -v &> install.log (I did ./make_it_so.sh skip beforehand, and it ended up giving similar error messages).
Thanks again!
Yeah, you chose poorly, or are unfortunate. The environment you have here is complicated, and I don’t have access to it. The way you have your environment setup, it is easy for either you or the environment in general to get confused. If you try to link against a pre-built CRTM that has been compiled with gfortran, this module configuration will not work.
I will not support the method outline above as it old/outdated (kickstart, etc), and should not exist IMO.
Look at make_it_so_discover_intel.bash, if you are using spack-stack it should be similar. Depending on the order in which you invoke your conda environment with this, you may need to load certain modules again so there isn’t a conflict between what the module wants, and what miniconda wants.
Alternatively, I would recommend doing a module purge, move your default loaded configuration to the side, and try make_it_so.sh and use keep everything in the conda environment avoiding this mix modules and I can give some level of assurance will work.
