I am attempting to simulate an eclipse on the single-column model (SCM) of the WRF model v4.4.2 that exists within the test branch for thesis work. I am unfamiliar with the bulk of the WRF suite as of the moment, but am somewhat familiar with the SCM portion. I am operating within JupyterLab v4.0.7 through a remote JetStream cloud server for the project. The host computer's OS is Windows. All files within the WRF test suite reset to a clean slate after the server is restarted, allowing for somewhat easier manipulation of files than if the files were permanently replaced and saved after each iteration.
Within README.namelist, a variable titled ra_sw_eclipse (line 611) controls whether or not the model takes into account eclipse patterns, particularly their effects on shortwave radiation. In order for this function to operate, this requires the eclipse_besselian_elements.dat to be present in the directory within which the WRF is operating (this file can be found on this GitHub repo here: Add Montornes's solar eclipse modelling (#1285) · xulinma/xulinma@ba98c77 - Ctrl+F for the file name will help in locating the file). This data file contains, as you might expect, the Besselian elements for various solar eclipses, contained in a numerous set of variables. I currently only understand a total of the first two, which contain year and day of year information. From those data points, I can extrapolate the events that are being referenced and pull up maps respective to these eclipses.
In order for me to utilize the eclipse function within the SCM test area of the WRF, I have one of two options:
1) Simulate my own eclipse
Given that the WRF code will accept that an eclipse is occurring and calculate its effects so long as the relevant information exists within eclipse_besselian_elements.dat, I can hypothetically create my own eclipse with custom parameters that I can then test the model with. This allows me to simulate an eclipse over the existing dataset, the effects of which would be seen in the model. Unfortunately, without knowing what each of the values represent in the code/reality, going about this process is nigh impossible with my current knowledge. If there is anyone with knowledge on this file that knows how the variables fit together, I would be grateful for an overview of which values correspond with the physical parameters they represent, since such information is not readily available within the code.
2) Move the sounding into an existing eclipse path
In my attempts to diagnose the issue that will be explained shortly, I sifted through each of the files contained within the test/em_scm_xy directory. In doing so, I noticed that several of the files used in the computation of the WRF (e.g. input_sounding, input_soil, GABLS_II_forcing.txt) are not affected by spatiotemporal bounds. As such, these files can hypothetically be altered to match the conditions of those present in other studies for comparison. The idea was to utilize the idealized sounding data, but shifted into another location in the path of an already existing eclipse. For the particular case I was attempting to simulate, the sounding was to be shifted to be located in Stuttgart, Germany for the August 11th, 1999 total solar eclipse. However, in order to retrieve the proper shortwave forcing present at these locations for their respective dates and times, the day of year, latitude, and longitude values present will need to change. As it turns out, this issue is more complex than replacing the code, as these spatiotemporal variables appear to be hardcoded into multiple files. The current crash statement reads as follows:
Domain # 1: dx = 4000.000 m
WRF V4.4.2 MODEL
git commit 1a2125ec2e1be5366b2171eab873f30768219ecf 3 files changed, 28 insertions(+), 29 deletions(-)
DYNAMICS OPTION: Eulerian Mass Coordinate
alloc_space_field: domain 1 , 9807996 bytes allocated
med_initialdata_input: calling input_input
Input data is acceptable to use: wrfinput_d01
CURRENT DATE = 1999-08-10_19:00:00
SIMULATION START DATE = 1999-08-10_19:00:00
Timing for processing wrfinput file (stream 0) for domain 1: 0.00374 elapsed seconds
Max map factor in domain 1 = 1.00. Scale the dt in the model accordingly.
INPUT LandUse = "USGS"
LANDUSE TYPE = "USGS" FOUND 61 CATEGORIES 2 SEASONS WATER CATEGORY = 16 SNOW CATEGORY = 0
INITIALIZE THREE Noah LSM RELATED TABLES
LANDUSE TYPE = USGS FOUND 27 CATEGORIES
INPUT SOIL TEXTURE CLASSIFICATION = STAS
SOIL TEXTURE CLASSIFICATION = STAS FOUND 19 CATEGORIES
Timing for Writing wrfout_d01_1999-08-10_19:00:00 for domain 1: 0.16719 elapsed seconds
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 314
Possibly missing file for = auxinput3
-------------------------------------------
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 314
Possibly missing file for = auxinput3
-------------------------------------------
Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
STOP wrf_abort
Of the twenty files that appeared in the directory after the crash, only the following files contained any trace of the base time (1999-10-22_19:00:00) and some or all of its counterparts in latitude, longitude, and end time: "forcing_file.cdl","force_ideal.nc","namelist.input","make_scm_forcing.ncl","core", and "namelist.output". Of these, the last two ("core" and "namelist.output") have been ruled out from being the cause of the issue due to being files reading in data as opposed to files that are being read from in relation to the time string listed above. It should be noted that "core" only intermittently appears, as it seems that it should delete itself after the model processes are complete. Aside from "core", all files and their amended counterparts (which will exist with EXP_ before them, meant to denote their experimental nature) will be attached to this message.
"namelist.input" is the easiest file to manipulate of the remaining four files potentially at the root of the issue, as it can be directly manipulated within JupyterLab. Dates, times, and coordinates were amended accordingly as seen in the EXP_ file. "make_scm_forcing.ncl" has a single instance of the base time string, which was altered to match the target scenario. Within "forcing_file.cdl", the only instances of the time string appearing are within the global attributes section on lines 184 and 185 and were altered accordingly. "force_ideal.nc" was the trickiest to manipulate, as it not being in a UTF-8 format made it impossible to manipulate directly within JupyterLab itself. The pieces of information altered are on lines 6 (twice, for start time) and lines 95 & 98 (end time) In order to alter this file, the file needed to first be downloaded from the em_scm_xy directory into a home directory using a script, downloaded from the home directory directly to my personal computer, opened in a text file, amended there, redownloaded back into the home directory, and finally use a script to replace the existing file in em_scm_xy with the now amended text file without replacing the name. The script in question is used extensively within my code to manipulate the movement of files from one directory to another, and is as follows:
!pip install os
import os
output_file = "/home/jovyan//EXP_force_ideal.nc"
directory = "/Build_WRF/WRF/test/em_scm_xy/force_ideal.nc"
os.system(f"cp {output_file} {directory}")
The error message as shown previously appears despite all these changes being made to their respective files. The file being called for does not match any known files in the directory, and the variable "auxinput3" appears in both "namelist.input" and "namelist.output". This variable seems linked to "force_ideal.nc", but even after double-checking the file to make sure the correct changes were implemented and that the file type was correct, the error still appeared.
If there is anyone who knows what might be happening with why the WRF keeps crashing, I would be grateful for the assistance.
Note: Some of the files will need to be converted back into their original file type to be useable by the model. These files are EXP_wrfinput_d01 (unknown if necessary) and EXP_force_ideal.nc (.txt to NC)
Within README.namelist, a variable titled ra_sw_eclipse (line 611) controls whether or not the model takes into account eclipse patterns, particularly their effects on shortwave radiation. In order for this function to operate, this requires the eclipse_besselian_elements.dat to be present in the directory within which the WRF is operating (this file can be found on this GitHub repo here: Add Montornes's solar eclipse modelling (#1285) · xulinma/xulinma@ba98c77 - Ctrl+F for the file name will help in locating the file). This data file contains, as you might expect, the Besselian elements for various solar eclipses, contained in a numerous set of variables. I currently only understand a total of the first two, which contain year and day of year information. From those data points, I can extrapolate the events that are being referenced and pull up maps respective to these eclipses.
In order for me to utilize the eclipse function within the SCM test area of the WRF, I have one of two options:
1) Simulate my own eclipse
Given that the WRF code will accept that an eclipse is occurring and calculate its effects so long as the relevant information exists within eclipse_besselian_elements.dat, I can hypothetically create my own eclipse with custom parameters that I can then test the model with. This allows me to simulate an eclipse over the existing dataset, the effects of which would be seen in the model. Unfortunately, without knowing what each of the values represent in the code/reality, going about this process is nigh impossible with my current knowledge. If there is anyone with knowledge on this file that knows how the variables fit together, I would be grateful for an overview of which values correspond with the physical parameters they represent, since such information is not readily available within the code.
2) Move the sounding into an existing eclipse path
In my attempts to diagnose the issue that will be explained shortly, I sifted through each of the files contained within the test/em_scm_xy directory. In doing so, I noticed that several of the files used in the computation of the WRF (e.g. input_sounding, input_soil, GABLS_II_forcing.txt) are not affected by spatiotemporal bounds. As such, these files can hypothetically be altered to match the conditions of those present in other studies for comparison. The idea was to utilize the idealized sounding data, but shifted into another location in the path of an already existing eclipse. For the particular case I was attempting to simulate, the sounding was to be shifted to be located in Stuttgart, Germany for the August 11th, 1999 total solar eclipse. However, in order to retrieve the proper shortwave forcing present at these locations for their respective dates and times, the day of year, latitude, and longitude values present will need to change. As it turns out, this issue is more complex than replacing the code, as these spatiotemporal variables appear to be hardcoded into multiple files. The current crash statement reads as follows:
Domain # 1: dx = 4000.000 m
WRF V4.4.2 MODEL
git commit 1a2125ec2e1be5366b2171eab873f30768219ecf 3 files changed, 28 insertions(+), 29 deletions(-)
DYNAMICS OPTION: Eulerian Mass Coordinate
alloc_space_field: domain 1 , 9807996 bytes allocated
med_initialdata_input: calling input_input
Input data is acceptable to use: wrfinput_d01
CURRENT DATE = 1999-08-10_19:00:00
SIMULATION START DATE = 1999-08-10_19:00:00
Timing for processing wrfinput file (stream 0) for domain 1: 0.00374 elapsed seconds
Max map factor in domain 1 = 1.00. Scale the dt in the model accordingly.
INPUT LandUse = "USGS"
LANDUSE TYPE = "USGS" FOUND 61 CATEGORIES 2 SEASONS WATER CATEGORY = 16 SNOW CATEGORY = 0
INITIALIZE THREE Noah LSM RELATED TABLES
LANDUSE TYPE = USGS FOUND 27 CATEGORIES
INPUT SOIL TEXTURE CLASSIFICATION = STAS
SOIL TEXTURE CLASSIFICATION = STAS FOUND 19 CATEGORIES
Timing for Writing wrfout_d01_1999-08-10_19:00:00 for domain 1: 0.16719 elapsed seconds
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 314
Possibly missing file for = auxinput3
-------------------------------------------
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 314
Possibly missing file for = auxinput3
-------------------------------------------
Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
STOP wrf_abort
Of the twenty files that appeared in the directory after the crash, only the following files contained any trace of the base time (1999-10-22_19:00:00) and some or all of its counterparts in latitude, longitude, and end time: "forcing_file.cdl","force_ideal.nc","namelist.input","make_scm_forcing.ncl","core", and "namelist.output". Of these, the last two ("core" and "namelist.output") have been ruled out from being the cause of the issue due to being files reading in data as opposed to files that are being read from in relation to the time string listed above. It should be noted that "core" only intermittently appears, as it seems that it should delete itself after the model processes are complete. Aside from "core", all files and their amended counterparts (which will exist with EXP_ before them, meant to denote their experimental nature) will be attached to this message.
"namelist.input" is the easiest file to manipulate of the remaining four files potentially at the root of the issue, as it can be directly manipulated within JupyterLab. Dates, times, and coordinates were amended accordingly as seen in the EXP_ file. "make_scm_forcing.ncl" has a single instance of the base time string, which was altered to match the target scenario. Within "forcing_file.cdl", the only instances of the time string appearing are within the global attributes section on lines 184 and 185 and were altered accordingly. "force_ideal.nc" was the trickiest to manipulate, as it not being in a UTF-8 format made it impossible to manipulate directly within JupyterLab itself. The pieces of information altered are on lines 6 (twice, for start time) and lines 95 & 98 (end time) In order to alter this file, the file needed to first be downloaded from the em_scm_xy directory into a home directory using a script, downloaded from the home directory directly to my personal computer, opened in a text file, amended there, redownloaded back into the home directory, and finally use a script to replace the existing file in em_scm_xy with the now amended text file without replacing the name. The script in question is used extensively within my code to manipulate the movement of files from one directory to another, and is as follows:
!pip install os
import os
output_file = "/home/jovyan//EXP_force_ideal.nc"
directory = "/Build_WRF/WRF/test/em_scm_xy/force_ideal.nc"
os.system(f"cp {output_file} {directory}")
The error message as shown previously appears despite all these changes being made to their respective files. The file being called for does not match any known files in the directory, and the variable "auxinput3" appears in both "namelist.input" and "namelist.output". This variable seems linked to "force_ideal.nc", but even after double-checking the file to make sure the correct changes were implemented and that the file type was correct, the error still appeared.
If there is anyone who knows what might be happening with why the WRF keeps crashing, I would be grateful for the assistance.
Note: Some of the files will need to be converted back into their original file type to be useable by the model. These files are EXP_wrfinput_d01 (unknown if necessary) and EXP_force_ideal.nc (.txt to NC)