ERROR: k.e. > 100

[zhongshi_zhang@bjerknes_uib_no]

Dear all,

I am using coupled CCSM4 with resolution T31_g37. I changed the initial condition for POP. But it crashes after I submit the job.

The error message shows that POP aborted.

POP aborting...
POP aborting...
POP aborting...
ERROR: k.e. > 100

ERROR: k.e. > 100
ERROR: k.e. > 100

Can any body tell me how to solve the problem? Thanks a lot.

Zhongshi

 

[njn01]

Dear all,

I am using coupled CCSM4 with resolution T31_g37. I changed the initial condition for POP. But it crashes after I submit the job.

The error message shows that POP aborted.

POP aborting...
POP aborting...
POP aborting...
ERROR: k.e. > 100

ERROR: k.e. > 100
ERROR: k.e. > 100

Can any body tell me how to solve the problem? Thanks a lot.

Zhongshi

The POP model monitors the kinetic energy diagnostic, and when it grows too large, the model shuts down, as you have discovered in your case.

If your case has been running successfully for some period of time before POP detects that K.E. is too large, that usually indicates a CFL problem, which can usually be solved by cutting the ocean-model timestep (increasing DT_COUNT -- see the POP User's Guide for details) by about 20%.

If, on the other hand, this problem occurs within days, or even steps, after ocean-model initialization, this usually indicates that the forcing coming into the POP model is way too strong, which is often caused by user setup error.

Because you say that you've changed the POP initial conditions, I suspect the latter. Did you use the "spunup" suboption when initializing T and S?

 

[zhongshi_zhang@bjerknes_uib_no]

The POP model monitors the kinetic energy diagnostic, and when it grows too large, the model shuts down, as you have discovered in your case.

If your case has been running successfully for some period of time before POP detects that K.E. is too large, that usually indicates a CFL problem, which can usually be solved by cutting the ocean-model timestep (increasing DT_COUNT -- see the POP User's Guide for details) by about 20%.

If, on the other hand, this problem occurs within days, or even steps, after ocean-model initialization, this usually indicates that the forcing coming into the POP model is way too strong, which is often caused by user setup error.

Because you say that you've changed the POP initial conditions, I suspect the latter. Did you use the "spunup" suboption when initializing T and S?

Thank you very much for the answer.

I did not used the "spunup" suboption. Could you tell me where I can flag it on?

 

[njn01]

The "spunup" suboption, described in the POP2 User's Guide, is only used when initializing a CESM startup run from an existing pop2 restart file. It is not a standard option -- eg, it does not appear in any cases created "out of the box" from the CESM Release Version scripts.

How long did your case run before hitting the KE "blowup?"

If it only ran for steps or days, then the most likely problem is the modifications you made to your case, and I recommend that you review your changes and make certain your changes are correct and reasonable. (And if you had said that you were using the "spunup" suboption, I would have also recommended that you confirm that the pop restart "header" file was also present in your execution directory. But this does not apply to your situation.)

If your case ran for a week or longer, the problem is most likely a CFL problem, and I would recommend decreasing your timestep and then re-running your case.

Did you run an "out-of-the-box" standard case first, before making any of your modifications? Did that case run correctly?