Repository navigation
MPC: scalar-point terms (component 0 or blank) name the scalar point's DOF - #334
Open
Valladarex wants to merge 1 commit into
Open
Valladarex wants to merge 1 commit into
Valladarex wants to merge 1 commit into
Conversation
…s DOF
MPC_PROC took the row of every MPC term as the point's first row + component - 1. A scalar point's component is 0, so it
named the last DOF of the point before it in the DOF table:
- a dependent scalar point stopped the run with ERROR 1517 (PROGRAMMING ERROR IN MPC_PROC; the row was not in the M-set);
- an independent one tied the equation to the wrong DOF without a message: an MPC GRID 1 T3 = u(1002), with scalar
point 1002 on a spring to the held scalar point 1001, gave GRID 1 T3 = 0 (that of 1001) instead of u(1002).
The M-set itself was right: TSET_PROC_FOR_MPCS already used component 1 for a dependent scalar point.
- MPC_PROC: an internal function MPC_TDOF_ROW gives the row of a term. A scalar point's component 0 (or 1) is its one DOF;
a component the point does not have stops with ERROR 1528 (0 on a grid, 2-6 on a scalar point, which before named the
next point's DOFs).
- TSET_PROC_FOR_MPCS: the same check for the dependent point, so component 0 on a grid stops with ERROR 1528 instead of
being put in the M-set as component 1.
- BD_MPC: the dependent component (field 4) may be blank, as the component of a scalar point is blank or 0. Fields 3 and 5
stay required (ERROR 1126). The independent components were already read as blank = 0.
Test (MYSTRAN_Validation): mpc_scalar_independent.bdf, GRID 1 T3 = u(1002) with 1002 on a spring k = 10 and a unit
load: GRID 1 T3 = u(1002) = 0.1 (hand values). Current dev gives GRID 1 T3 = 0 without a message.
Collaborator
|
Do you think it's better to allow SPOINT's component = 0 internally like this seems to do, or to keep it as component = 1 internally but when reading the card, convert 0 and blank to 1? I think the latter is a much simpler change. Not sure if there's any other consequence of having component=0 floating around. |
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.
Fixes #333.
One commit, in
Source/LK1/L1D/MPC_PROCESSING.f03,Source/LK1/L1B/DOF_SET_CONSTRUCTION.f03andSource/LK1/L1A-BD/CONSTRAINT_CARDS.f03.Test: MYSTRAN_Validation MystranSolver/MYSTRAN_Validation#43,
mpc_scalar_independent.bdf: GRID 1 T3 = u(1002) with 1002 on a spring k = 10 and a unit load.dev, GRID 1 T3 = 0 without a message, so that check fails. The u(1002) check is a control that passes on both. With this PR both pass.Also checked on this commit alone, outside the suite:
Validation suite: with both PRs, 1 failure of 3,257 checks, the same one current
devhas without them ("mitc4 thermal strain free rectangle cylinder"). The new checks pass.