memory leak when using vector mapping for Sa_u and Sa_v
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- fortran
- Domain
- data-engineering
Research direction
Start by checking out the feature-support_CESM_RYF_mv branch and running the 1850_DATM%JRA-RYF8485_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP compset with Sa_u:Sa_v vector mapping. Compare memory behavior after changing the CORE_RYF8485_JRA stream's vectors setting to null, and trace the CDEPS handling shared by CORE2_NYF.NCEP and ERA5_HOURLY; done means the vector mapping no longer leaks memory.
Written by the indexing model from the issue text.
Description
There is a large memory leak when vector mapping used for the stream RYF streams such as
<stream_info name="CORE_RYF8485_JRA.NCEP">
If for this stream - you replace
< <vectors>Sa_u:Sa_v</vectors>
with
> <vectors>null</vectors>
There is no longer a memory leak.
So this is definitely a problem in CDEPS.
This vector mapping is also used in CORE2_NYF.NCEP and ERA5_HOURLY
It's interesting that for CORE_IAF_JRA the Sa_u and Sa_v actually come in from different streams
CORE_IAF_JRA.U_10
CORE_IAF_JRA.V_10
I am using a CDEPS branch that actually turns on this capability.
fork: https://github.com/mvertens/CDEPS
branch: feature-support_CESM_RYF_mv
You can see the memory leak by simply running the compset
1850_DATM%JRA-RYF8485_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP
- Dominant language
- Fortran
- Stars
- 32
- Forks
- 71
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 2
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ESCOMP/CDEPS
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
CESM Only enhancement question
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
If statements in DATM buildnml wrongly assume False if the value is 0.0May be free again @ekluzek claimed this 40 days ago, and no pull request is open. Openbug Responsibility: CTSM
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
laaielichter/Gulliver#21 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
enhancement implementation: easy priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
suarezgenaro/seda#162 ·
Maintainers usually reply within 1 day