There is a for loop that loops over files by year and CMORizes. In PR #213, I moved the call to cmor.close() after each iteration of this for loop. This causescmor to reset the internal mapping ID for the cmor.variable object back to 0. As a result, the second iteration attempts to write to the same file as the first iteration, rather than having a distinct file.
Example:
1. For year 1 -> cmor_axis_id = 0 -> good to go
2. For year 2 -> cmor_axis_id = 0 -> seg fault (clashing IDs and files)
What did you expect to happen? Are there are possible answers you came across?
What happened?
There is a for loop that loops over files by year and CMORizes. In PR #213, I moved the call to
cmor.close()
after each iteration of this for loop. This causescmor
to reset the internal mapping ID for thecmor.variable
object back to 0. As a result, the second iteration attempts to write to the same file as the first iteration, rather than having a distinct file.Example:
What did you expect to happen? Are there are possible answers you came across?
cmor.close()
fromVarHandler_cmor_write()
https://github.com/E3SM-Project/e3sm_to_cmip/blob/30d40c19c9e9c81eb95fb127a25cf2eaaa5ee572/e3sm_to_cmip/cmor_handlers/handler.py#L676-L679cmor.close()
at the end ofVarHandler.cmorize()
, after the for loop https://github.com/E3SM-Project/e3sm_to_cmip/blob/30d40c19c9e9c81eb95fb127a25cf2eaaa5ee572/e3sm_to_cmip/cmor_handlers/handler.py#L260-L262Example:
Minimal Complete Verifiable Example (MVCE)
Relevant log output
No response
Anything else we need to know?
I did not catch this bug in PR #213 because the end-to-end testing script only tests for 1 year.
Environment
e3sm_to_cmip=1.11.0
andmaster
branch