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

MLE% wackiness in input files #539

Closed
kshedstrom opened this issue Jan 5, 2024 · 5 comments
Closed

MLE% wackiness in input files #539

kshedstrom opened this issue Jan 5, 2024 · 5 comments

Comments

@kshedstrom
Copy link

If one uses MLE%USE_BODNER23, things behave as expected. Instead, the parameter_doc.short file lists it as:

MLE%
USE_BODNER23 = True
%MLE

with some other stuff in there. The problem is that the register_restarts routine for this only allocates some of the work arrays if MLE%UES_BODNER23 is True. This second check isn't checking for the MLE environment. Things then fail when the work arrays are used if not allocated.

@kshedstrom
Copy link
Author

I tried fixing the register_restart routine, but it still doesn't correctly parse the:

MLE%
USE_BODNER23 = True
%MLE

The bug I had heard a rumor of is not this bug but something deeper.

Just a note: openParameterBlock and closeParameterBlock don't now have a donotlog sort of option - it might be nice when used with parameter calls that are not logged.

@marshallward
Copy link
Member

marshallward commented Jan 9, 2024

I think that I can reproduce something relevant in .testing/tc2.a. This works:

MLE%USE_BODNER23 = True
MLE%BLD_DECAYING_TFILTER = 86400.
MLE%MLD_DECAYING_TFILTER = 259200.
MLE%BLD_GROWING_TFILTER = 300.
MLE%MLD_GROWING_TFILTER = 3600.

but if I use this:

MLE%
USE_BODNER23 = True
BLD_DECAYING_TFILTER = 86400.
MLD_DECAYING_TFILTER = 259200.
BLD_GROWING_TFILTER = 300.
MLD_GROWING_TFILTER = 3600.
%MLE

then I get the following error:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7fae4e966b4f in ???
#1  0xab9c84 in rmean2ts
	at ../../../src/parameterizations/lateral/MOM_mixed_layer_restrat.F90:1162
#2  0xabba53 in mixedlayer_restrat_bodner
	at ../../../src/parameterizations/lateral/MOM_mixed_layer_restrat.F90:886
#3  0xacbc12 in __mom_mixed_layer_restrat_MOD_mixedlayer_restrat
	at ../../../src/parameterizations/lateral/MOM_mixed_layer_restrat.F90:155
#4  0x4738e1 in step_mom_dynamics
	at ../../../src/core/MOM.F90:1330
#5  0x477fd5 in __mom_MOD_step_mom
	at ../../../src/core/MOM.F90:912
#6  0x7bffc4 in mom6
	at ../../../config_src/drivers/solo_driver/MOM_driver.F90:485
#7  0x7c1530 in main
	at ../../../config_src/drivers/solo_driver/MOM_driver.F90:27

I am unsure if this is related to your error, which seems related to restart files, but it's certainly a rather serious error.

@marshallward
Copy link
Member

Looks like use_bodner is set to false, despite the parameter being set to true.

p cs%mixedlayer_restrat_csp
$1 = ( ... , use_bodner = .FALSE., ..., mld_filtered = <not allocated>, mld_filtered_slow = <not allocated>, ...)

and explains why MLD_filtered is unallocated, which is causing the SIGSEGV.

This is probably a file parser error, that is probably the next place to look.

kshedstrom added a commit to ESMG/MOM6 that referenced this issue Jan 9, 2024
@marshallward
Copy link
Member

@kshedstrom I think this is fixed now, can we close it?

@kshedstrom
Copy link
Author

Yes, fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants