Serialize element-level rho in quad/triangle elements (fixes garbage mass on DB restore / MPI) - #31
Open
nmorabowen wants to merge 1 commit into
Open
Conversation
FourNodeQuad, FourNodeQuad3d, EightNodeQuad, NineNodeQuad, SixNodeTri and Tri31 select their mass density as: if the element-level rho is nonzero use it, otherwise fall back to the material density. But sendSelf/recvSelf never packed rho into the data Vector, and every blank (broker) constructor except FourNodeQuad3d left rho uninitialized. So after a database restore or an OpenSeesMP send, rho held garbage heap data: a nonzero garbage value then hijacked the mass matrix, giving a non-deterministic, often indefinite M (negative generalized eigenvalues) and diverging transient restarts. Fix (additive): append rho to each element's send/recv data Vector (+1 slot) and initialize rho(0.0) in the blank constructors that lacked it. Committed nodal displacements round-trip unchanged, so a plain nodeDisp restore test did not expose this; it only shows once the restored model integrates in time. Wire-format note: the send/recv Vector grows by one slot, so a model saved or sent by this build is not binary-compatible with a stock-built peer for these element types. This matters only for mixed-build database restore / MPI runs. Co-authored-by: Patricio Palacios <pxpalacios@miuandes.cl> Co-authored-by: Jose A. Abell <jaabell@miuandes.cl>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
FourNodeQuad,FourNodeQuad3d,EightNodeQuad,NineNodeQuad,SixNodeTriandTri31pick their mass density as "if element-levelrhois nonzero use it, else fall back to the material density." ButsendSelf/recvSelfnever packedrhointo the dataVector, and every blank (broker) constructor exceptFourNodeQuad3dleftrhouninitialized.So after a
databaserestore or an OpenSeesMP send,rhoheld garbage heap data. A nonzero garbage value then hijacked the mass matrix → non-deterministic, often indefinite M (negative generalized eigenvalues) and diverging transient restarts.Fix (additive)
rhoto each element's send/recv dataVector(+1 slot).rho(0.0)in the blank constructors that lacked it.Committed nodal displacements round-trip fine, so a plain
nodeDisprestore test does not expose this — it only shows once the restored model integrates in time.Wire-format note
The send/recv
Vectorgrows by one slot for these element types, so a model saved/sent by this build is not binary-compatible with a stock-built peer for those elements. This only matters for mixed-build database-restore / MPI runs.Authors: Nicolas Mora Bowen, Patricio Palacios, José A. Abell