Runing WRF: Stack memory problem about wrf-suews HOT 29 CLOSED

where are you running wrf?
on the login node or sci node?

from wrf-suews.

sci node! The command fixed the problem and wrf was run successfully

from wrf-suews.

Good job!
Have you tried to run this by submitting jobs? i.e., bsub task_script?

from wrf-suews.

Not yet, I will try. But I assume there wouldn't any problem if I submit the job

from wrf-suews.

Great!
A sample bsub script bsub_run_wrf may look like the following:

#!/bin/bash 
#BSUB -q par-multi 
#BSUB -n 120
#BSUB -o %J.out 
#BSUB -e %J.err 
#BSUB -W 08:30

echo "Running WRF"
mpirun ./wrf.exe

then

bsub bsub_run_wrf

from wrf-suews.

Great, Thanks!

from wrf-suews.

this tip has been added in JASMIN tips

from wrf-suews.

I started running WRF for the London data. It was running for about one hour (I submitted the job), and it gave severe (174): SIGSEGV, segmentation fault occurred . I am suspecting it is again a memory problem, and trying to see if it can get fix. Do you have any suggestion?

from wrf-suews.

is this v4 or v3.9?

from wrf-suews.

and on which node did you submit your job?

from wrf-suews.

that is probably an array dimension or a subroutine passing problem (eg. real instead of integer)

from wrf-suews.

It is V4. I submitted on sci1. Does it matter which one?

from wrf-suews.

Memory-demanding jobs should go to sci3:
https://help.jasmin.ac.uk/article/121-sci-servers

from wrf-suews.

Got it! I started running in sci3. Actually, I found out if we run on sci3, we would not have the stack problem initially (ulimit -u unlimited) meaning that sci3 has bigger stack memory!
I will update here if I could run the entire London data successfully

from wrf-suews.

Update: The run again stopped at some point (later than the previous time). I suspected that it might have the stability problem, and found 11 points exceeded cfl=2 in the rsl files (and shortly after this, the run gave the same error). So possible solution is reducing the time step, right?

from wrf-suews.

yes, let's give it a try.
But this is indeed weird!

BTW, where is your working directory? I might have a look later this afternoon.

from wrf-suews.

Here: /home/users/homidvar

from wrf-suews.

I cannot visit your folder due to permission reason.
But I just checked, you should be able to visit my folder on /work/scratch below:
/work/scratch/sunt05.

If so, let's collaborate there.

from wrf-suews.

Definitely a stability problem: look at the plots of U10 for the last two written times:

from wrf-suews.

I can visit your folder in your scratch but won't be able to edit any file. It should be the same for you. I will copy my files in scratch and start working on it, then you should be able to visit my scratch folder
/work/scratch/homidvar

from wrf-suews.

Great!
Good spot: re the U10 issue.

OK, let's work on scratch for now so at least we can see something.

from wrf-suews.

@hamidrezaomidvar how is the run going? did a finer time step resolve the issue?

from wrf-suews.

@sunt05 It is still running. I am using an adaptive time step to make sure if it fails again, it will not a time step problem. I will let you know when it finishes.

from wrf-suews.

I can confirm that the WRF run with London data finished successfully using the adaptive time step.

from wrf-suews.

Great!
Just about to ask you on this.

from wrf-suews.

And I've created a folder here:
/work/scratch/WRF-SUEWS-test
I think now it has a widely open permission that allows anyone for writing, reading and execution.
Can you try to make a dir there?

Then we can collaborate there.

from wrf-suews.

Yes Just did that. I will copy my stuff there and will work on them in this directory from now on

from wrf-suews.

Just a quick note about Adaptive time step in WRF:
Adaptive time step calculates the CFL number and compares it with a target CFL number, then it changes the time step depending on the comparison result (to fulfill the stability of the model). This paper explains this method.
To turn on the adaptive time step, in &domain of namelist.input, we need to add this:
use_adaptive_time_step = .true.
This will also ignore the time_step value. This method has other properties and controlling parameters that can be found here.

from wrf-suews.

Good job! @hamidrezaomidvar

from wrf-suews.