Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

If no problem type is specified in .config file, "EISMINT" error occurs #10

Open
billsacks opened this issue Jul 6, 2018 · 2 comments
Labels
enhancement New feature or request

Comments

@billsacks
Copy link
Member

From @matthewhoffman on July 28, 2015 15:23

If no problem type is specified in the .config file, CISM aborts with:
FATAL ERROR : No EISMINT forcing selected

There is no documentation for how a user should set up a user-defined simulation that is not one of the canned test cases. The modules that parse the .config file look for different domain types as a config section in square brackets. For instance, an EISMINT-2 test has a [EISMINT-2] section (with some items beneath it), a dome test has a [DOME-TEST] section (with no items beneath it). Currently the code is expecting one of these problem types to be specified, and if one isn't then it throws the error "FATAL ERROR : No EISMINT forcing selected".

A workaround for running a user-defined problem is to add the line:
[DOME-TEST]
to the .config file. The dome test is a generic problem type and can be used for any user-defined simulations. This line simply tells CISM that nothing special needs to occur in setting up the problem. Ideally we should generalize this so that for a generic problem either

  1. no problem type needs to be defined at all; or
  2. we have something like a [GENERIC] problem type that makes it explicit that nothing unusual needs to occur inside the model set up.

Copied from original issue: E3SM-Project/cism-piscees#38

@billsacks billsacks added the enhancement New feature or request label Jul 6, 2018
@billsacks
Copy link
Member Author

From @whlipscomb on July 28, 2015 23:11

@matthewhoffman , I've never liked this old Glimmer feature. My preference would be (1): If no problem type is supplied by the user, then the model runs on without doing anything special.

@billsacks
Copy link
Member Author

From @DanFMartin on July 29, 2015 4:52

I'd concur with Bill -- One of the issues we ran into when coupling CISM
to BISICLES and running our own problems was figuring out what the
problem type needed to be when we were setting up our own problems. At
some point in the process, things changed under us, and I had to just
try various problem types until I found one which worked again.

A generic problem type would have simplified that.

Dan

On 07/28/2015 04:11 PM, William Lipscomb wrote:

@matthewhoffman https://github.com/matthewhoffman , I've never liked
this old Glimmer feature. My preference would be (1): If no problem type
is supplied by the uses, then the model runs on without doing anything
special.


Reply to this email directly or view it on GitHub
https://github.com/ACME-Climate/cism-piscees/issues/38#issuecomment-125778630.


Dan Martin email: DFMartin@lbl.gov
Mail Stop 50A-1148 phone: (510) 495-2852
Lawrence Berkeley National Laboratory fax: (510) 486-6900
1 Cyclotron Rd.
Berkeley, CA 94720

billsacks pushed a commit that referenced this issue Jun 23, 2021
Add initialization with unstaggered temperature from glide
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant