Push notifications in your browser are not yet configured.
You are not logged in, you may not see all content and functionalities. If you have an account, please login .
Configuring CCLM for Middle East
Dear colleagues,
I am attempting to run the model run using nesting (cclm_to_cclm) over a Middle Eastern (me) domain with the cclm-sp-1.3.4 starter. External files for both the coarse resolution and nested runs have been created using the PEP on the cclm-community website. The me002 run stops during the int2lm
stage after reading lffd*c.nc file available from the me001 (see its ncdump -h attached). In a separate me2.tar file I also attach several other files for/from the run. Additionally, I attach corresponding files from the sp002 simulations which was fully based on the data from the training course. As I have noticed, external file (its content) provided by you for the sp002 run differs significantly from that created for my me002 experiment. Can this be the cause for my problem? And another question – how can I create such external file for my simulation domain?
Best regards, Simon
We talked about this in the recent trainings course.
Please check items 3 and 4 on the troubleshooting page (login requested)
http://www.clm-community.eu/index.php?menuid=164
and change the int2lm namelist accordingly.
However, a better alternative may be to recreate the external data file with the EXTPAR option instead of the PEP one. In the near future the PEP option will become obsolete when the new EXTPAR version will be released.
Dear colleagues,
I am attempting now to start runiung cclm-sp_1.4 package over CORDEX _MENA domain on our linux machine.
Some progress may be reported – the original cclm-sp_1.4 has been successfully implemented (by Alon Shtivelman with some my participation). I have included the Fopts files used in the tar file attached.
Our efforts to start running the new version over the CORDEX _MENA domain (using ERA -Int) driving data have been much less successful however.
Since I already have a cclm-sp-1.3.3 version for this experiment ready I attemted to make exactly (I think) the same changes to the template/cclm.job template/int2lm.job and subchain file as those I made for the cclm-sp-1.3.3 case. Please see the results in the ccint2lm.o600038.
Please let me know your recommendations.
Regards,
Simon Krichak
The grid points of the external data and the int2lm grid do not match. The external data set can be larger than the domain defined for the CCLM , but in the overlapping region the grid points must match.
In your output you can read
Here (-48.4 – (-38.0))/0.44 = -23.63637 and (-28.6 – (-7))/0.44= 40.09091, but the results have to be whole numbers.
You did not send the template int2lm.job.tmpl for version 14. Please check if the following
Hi,
Thank you. Still do not know what to do. My problem, as I see it, is that I am using exactly (I hope) same setup data in my 1.3.3 and 1.4 versions. With the only difference – the 1.4 crashes. Please see attached all the data I have.
Best,
Simon
I am not sure what happens in 1.3.3, but the int2m job can definitely not run with the startlon=-38. and startlat=-7. and domain2013112115045.nc unless you made some manipulations in the int2lm code. If you use startlon=-38.28 and startlon=-7.04 it should work. See the ncdump of the rlon/rlat in the following from domain2013112115045.nc. I does not contain a -38. for rlon and not a -7. for rlat:
rlon = -48.4, -47.96, -47.52, -47.08, -46.64, -46.2, -45.76, -45.32, -44.88, -44.44, -44, -43.56, -43.12, -42.68, -42.24, -41.8, -41.36, -40.92, -40.48, -40.04, -39.6, -39.16, -38.72, -38.28, -37.84, -37.4, -36.96, -36.52, -36.08, -35.64, -35.2, -34.76, -34.32, -33.88, -33.44, -33, -32.56, -32.12, -31.68, -31.24, -30.8, -30.36, -29.92, -29.48, -29.04, -28.6, -28.16, -27.72, -27.28, -26.84, -26.4, -25.96, -25.52, -25.08, -24.64, -24.2, -23.76, -23.32, -22.88, -22.44, -22, -21.56, -21.12, -20.68, -20.24, -19.8, -19.36, -18.92, -18.48, -18.04, -17.6, -17.16, -16.72, -16.28, -15.84, -15.4, -14.96, -14.52, -14.08, -13.64, -13.2, -12.76, -12.32, -11.88, -11.44, -11, -10.56, -10.12, -9.68, -9.24, -8.8, -8.36, -7.92, -7.48, -7.04, -6.6, -6.16, -5.72, -5.28, -4.84, -4.4, -3.96, -3.52, -3.08, -2.64, -2.2, -1.76, -1.32, -0.88, -0.44, 0, 0.44, 0.88, 1.32, 1.76, 2.2, 2.64, 3.08, 3.52, 3.96, 4.4, 4.84, 5.28, 5.72, 6.16, 6.6, 7.04, 7.48, 7.92, 8.36, 8.8, 9.24, 9.68, 10.12, 10.56, 11, 11.44, 11.88, 12.32, 12.76, 13.2, 13.64, 14.08, 14.52, 14.96, 15.4, 15.84, 16.28, 16.72, 17.16, 17.6, 18.04, 18.48, 18.92, 19.36, 19.8, 20.24, 20.68, 21.12, 21.56, 22, 22.44, 22.88, 23.32, 23.76, 24.2, 24.64, 25.08, 25.52, 25.96, 26.4, 26.84, 27.28, 27.72, 28.16, 28.6, 29.04, 29.48, 29.92, 30.36, 30.8, 31.24, 31.68, 32.12, 32.56, 33, 33.44, 33.88, 34.32, 34.76, 35.2, 35.64, 36.08, 36.52, 36.96, 37.4, 37.84, 38.28, 38.72, 39.16, 39.6, 40.04, 40.48, 40.92, 41.36, 41.8, 42.24, 42.68, 43.12, 43.56, 44, 44.44, 44.88, 45.32, 45.76, 46.2, 46.64, 47.08, 47.52, 47.96, 48.4, 48.84, 49.28, 49.72, 50.16, 50.6, 51.04, 51.48, 51.92, 52.36, 52.8, 53.24, 53.68, 54.12, 54.56, 55, 55.44, 55.88, 56.32, 56.76, 57.2, 57.64, 58.08, 58.52, 58.96, 59.4, 59.84, 60.28, 60.72, 61.16, 61.6, 62.04, 62.48, 62.92, 63.36, 63.8, 64.24, 64.68, 65.12, 65.56, 66, 66.44, 66.88, 67.32, 67.76, 68.2, 68.64, 69.08, 69.52, 69.96, 70.4, 70.84, 71.28, 71.72, 72.16, 72.6, 73.04, 73.48, 73.92, 74.36, 74.8, 75.24, 75.68, 76.12, 76.56, 77, 77.44, 77.88, 78.32, 78.76, 79.2, 79.64, 80.08, 80.52, 80.96, 81.4, 81.84, 82.28, 82.72, 83.16, 83.6, 84.04, 84.48, 84.92, 85.36, 85.8, 86.24, 86.68, 87.12, 87.56, 88, 88.44, 88.88, 89.32, 89.76, 90.2, 90.64, 91.08, 91.52, 91.96, 92.4, 92.84, 93.28, 93.72, 94.16, 94.6, 95.04, 95.48, 95.92, 96.36, 96.8, 97.24 ; }Hi,
I’ve made the correction suggested (startlon=-38.28 and startlon=-7.04)and have now another problem with segmentation fault during the int2lm stage. I re-ran it with higher debug level. Please have a look at the file attached with (apparently) all the info possible.
Best,
Simon
Since your boundary data are ERAI nterim, you have QI available in the boundary data. Therefore instead of lprog_qi = .FALSE.,
please try with lprog_qi = .TRUE.,
Hi,
I have successfully ran the cclm-sp-1_4 for 2 months but then there is a problem at the end of third month of my experiment.
As far as I know I use exactly the same ERA -Interim files as those I use with the cclm-sp-1.3.4.
In the arttachment you please find the logouts from my cclm run with high level of debugging and also restart (no debbuging).
Please let me know your recommendations.
Simon
Hi Simon,
That’s very nice that you fell into that trap because since yesterday I am discussing the problem again with DWD (I did it already several times).
The problem is that you want to (over)write restart files which already exist in your restart directory.
This fails since the status of such a file in the corresponding open-statement (in io_utilities.f90) is NEW .
To my opinion this is unlucky, but COSMO don’t want to change it from NEW to, for example, UNKNOWN .
So, what can you do?
1. delete the already existing restart files in your restart directory
or, if you want to keep these restart files
2. create a new restart directory and write into this new dir.
Hans-Juergen