Closed ghost closed 3 years ago
Hi Nick, I believe that generally when I have seen errors in the core physics from WRF, it is often a problem with the inputs. One thing that jumps to mind is the order of the vertical dimension. Do you have 1000hPa (or 0m ASL or AGL) as the first level in the vertical dimension? If it is the last level the code will break.
I would recommend that while you are still testing, you may want to turn off most of the physics parameterizations to make it as simple as possible. You could even set wind=0 to turn off the linear theory perturbation. pbl = 0 ! Simple lsm = 0 ! Noah water = 0 ! simple mp = 2 ! simple rad = 0 ! simple conv = 0 ! Tiedke Scheme adv = 1 ! upwind wind = 1 ! linear theory
On Jul 17, 2017, at 12:15 PM, Nick Dawson notifications@github.com wrote:
I'm tracking down whether this is a problem with the input data or the code itself. ICAR was built with MODE=debugslow on Intel compilers. About 30% of the way through the first time step an error forrtl: error(73): floating divide by zero occurs. The domain is situated over Idaho.
Physics Options:
pbl = 2 ! Simple lsm = 3 ! Noah water = 2 ! simple mp = 2 ! simple rad = 2 ! simple conv = 1 ! Tiedke Scheme adv = 1 ! upwind wind = 1 ! linear theory The traceback provides the following (edited) information:
Routine Line Source module_cu_tiedtke 2923 cu_tiedtke.f90 module_cu_tiedtke 1211 cu_tiedtke.f90 module_cu_tiedtke 648 cu_tiedtke.f90 module_cu_tiedtke 443 cu_tiedtke.f90 convection_mp_con 153 cu_driver.f90 time_step_mp_step 477 time_step.f90 MAIN__ 90 driver.f90 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NCAR/icar/issues/34, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOgXtDak_AGxGrqKwzE-0PlDJJTomONks5sO4Y3gaJpZM4OaJx5.
Using the simplified options (along with wind=0), the model ran. Wind values are provided for all time steps but after the first time step the ta2m output is blank (missing values). I'm pretty sure this happens because nearly everything is turned off.
The problem must be the input files. Input files are created from CFSv2 data in WPS. Two runs of ungrib are needed to provide the 3D data and the surface data. I've added variables to the ungrib/metgrid tables to provide the necessary inputs for icar. Looking at the "Z" field, the first metgrid level ranges between 600-1300 gpm. But the next level starts at ~100 gpm and increases monotonically up to ~45,000 gpm thereafter.
ICAR does provide a warning, "Forcing Z levels are below the terrain provided. For pressure level forcing data this is expected, but not well tested."
Hi Nick, have you made any more progress on this? Does it work with other input files so we can close this?
I wasn't able to get things working and moved on to testing MPAS. I will give it another shot tomorrow and see if I can get ICAR running with CFSv2 inputs.
OK, if you have a minimal forcing dataset you can post that reproduces this error, let me know and I'll take a look at it.
What is the minimal forcing needed in order run ICAR with nearly all parameterizations turned off? Is it simply a wind field, lat(u,v)/lon(u,v), Z, and heights? The current CFSv2 inputs are too large (217MB) to share via github. I assume the &var_list can also be trimmed down with the following &physics options?
Here's what I mean when I say turn off parameterizations &physics pbl = 0 lsm = 0 water = 0 mp = 2 rad = 0 conv = 0 adv = 1 wind = 0
You also need (potential) temperature, water vapor and pressure. 217MB isn’t very large though, I can set up an FTP site for you to upload to, I’ll email directly with an ftp site.
ethan
On Aug 1, 2017, at 10:10 AM, Nick Dawson notifications@github.com wrote:
What is the minimal forcing needed in order run ICAR with nearly all parameterizations turned off? Is it simply a wind field, lat(u,v)/lon(u,v), Z, and heights? The current CFSv2 inputs are too large (217MB) to share via github. I assume the &var_list can also be trimmed down with the following &physics options?
Here's what I mean when I say turn off parameterizations &physics pbl = 0 lsm = 0 water = 0 mp = 2 rad = 0 conv = 0 adv = 1 wind = 0 https://github.com/NCAR/icar/issues https://github.com/NCAR/icar/issues — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NCAR/icar/issues/34#issuecomment-319418451, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOgXkt33kqcmypsXCbrzvVoQiTxdXYoks5sT04KgaJpZM4OaJx5.
I decreased the grid spacing of the forcing files so they are much smaller now, but I will still need to send via FTP.
Nick Dawson, Ph.D. ATMOSPHERIC SCIENTIST Idaho Power | Power Supply
Work 208-388-5291 Mobile 208-860-0954
From: Ethan Gutmann [mailto:notifications@github.com] Sent: Tuesday, August 01, 2017 10:34 AM To: NCAR/icar icar@noreply.github.com Cc: Dawson, Nick NDawson@idahopower.com; Author author@noreply.github.com Subject: [EXTERNAL] Re: [NCAR/icar] cu_tiedtke.f90 divide by zero (#34)
You also need (potential) temperature, water vapor and pressure. 217MB isn’t very large though, I can set up an FTP site for you to upload to, I’ll email directly with an ftp site.
ethan
On Aug 1, 2017, at 10:10 AM, Nick Dawson notifications@github.com<mailto:notifications@github.com> wrote:
What is the minimal forcing needed in order run ICAR with nearly all parameterizations turned off? Is it simply a wind field, lat(u,v)/lon(u,v), Z, and heights? The current CFSv2 inputs are too large (217MB) to share via github. I assume the &var_list can also be trimmed down with the following &physics options?
Here's what I mean when I say turn off parameterizations &physics pbl = 0 lsm = 0 water = 0 mp = 2 rad = 0 conv = 0 adv = 1 wind = 0 https://github.com/NCAR/icar/issues https://github.com/NCAR/icar/issues — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NCAR/icar/issues/34#issuecomment-319418451, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOgXkt33kqcmypsXCbrzvVoQiTxdXYoks5sT04KgaJpZM4OaJx5.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NCAR/icar/issues/34#issuecomment-319425250, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AcBLKtV9Fr0bt5komeJELBZjUFwlYhZIks5sT1OAgaJpZM4OaJx5.
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under
applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If
you received this transmission in error, please immediately contact the sender and destroy the material in its
entirety, whether in electronic or hard copy format. Thank you.
Given how many other things have changed since this was opened, I'm going to close this for now. We can always come back to this with a test case in the future.
I'm tracking down whether this is a problem with the input data or the code itself. ICAR was built with MODE=debugslow on Intel compilers. About 30% of the way through the first time step an error
forrtl: error(73): floating divide by zero
occurs. The domain is situated over Idaho.Physics Options:
The traceback provides the following (edited) information: