You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
no problem type needs to be defined at all; or
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
The text was updated successfully, but these errors were encountered:
@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.
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:
@matthewhoffmanhttps://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.
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
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
[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
The text was updated successfully, but these errors were encountered: