Restart files for ruser_meshblock_data size varying by block #709
Replies: 3 comments
-
|
To be honest, I just made all meshblocks have the same size even if I only used the user meshblock data on a boundary. While this does increase your memory footprint and restart file size, I found that it was not prohibitive. |
Beta Was this translation helpful? Give feedback.
-
|
In my particular case it is becoming very large but I don't require any information from the actual simulation as the ruser_mesblock_data are external data for data-driving (on the one z-boundary) and/or scratch arrays for lazy communications/calculations in the meshblock and mesh WorkInLoop functions. I think my best bet is to disable the rusermeshblock write and read all together and just let the InitUserMeshData and InitUserMeshBlockData (hopefully) take over and populate without any dramas. I'm having an issue with my dumb solution of just skipping the memcpy() action, the other data doesn't seem to be loaded correctly from the InitUserMeshData and InitUserMeshBlockData functions - or something is going wrong after they have been run and the memcpy() is skipped for the isuer and ruser structures. Any advice would be appreciated while I debug this. |
Beta Was this translation helpful? Give feedback.
-
|
If you just want to read the same file every time for the boundary, probably there is no real advantage to use the user-defined mesh(block) data. Instead, as you suggested, just allocating some memory and filling it in InitUserMesh(Block)Data should suffice. You might be messing up something with the user_mesh(block)_data structures. Instead, I would suggest you to just define an array (or AthenaArray) as a global variable (with a namespace if you wish) somewhere in your pgen file. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Current restarts with user meshblock data (and ruser mesh data) only support identically sized data (invariant with meshblock). In the case where large data will only be needed for some blocks, on one z-boundary for example, then the data footprint can be dramatically reduced.
This involves changing the headeroffset in the read/write (I think). Does anyone have any suggestions or advice for accomplishing this?
Beta Was this translation helpful? Give feedback.
All reactions