Fixed some output requests, better data types#269
Merged
Conversation
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.
This PR is all about the "specifiers" in Case Control output requests, such as
PRINT,PLOT, andPUNCH. You can put them in parens in output requests to direct them to the F06, OP2 and PCH files respectively.However, the way it was done before was bad for four reasons:
DISPLACEMENT = ALL) would never produce OP2 output (issue: DISP=ALL doesn't write to OP2 with PARAM,POST,-1 #177)Y/Nstrings and magic indices all over the place.L1A-CCsubroutines.So here's what I did:
OUTPUT_TARGETS, in theDERIVED_DATA_TYPESmodule. It holds three booleans, they indicate whether to write that result to F06, OP2, and PCH respectively. This supersedes the strings and magic indices, fixing issue 3.COMPUTE_OUTPUT_TARGETS, so no more code repetition (hence the negative line delta), fixing issue 4.PLOTalone -- as one does in commercial solvers like MSC -- and fixed issue 2.Here are the caveats:
PARAM,POST. We need to address that. One of the proposals being floated is to have a non-negativePARAM,POSTcompletely disable OP2 writing.PARAM,POSTand warrants further investigation and discussion.Oh, and three bonus changes:
PRTOP2andPRTF06. All they did was override the strings to be all-Y. This is in line with our current efforts to make MYSTRAN more compatible with other solvers._Interfaceor_USE_IFsfiles. It exists in a module and is imported from there. This is a sign of things to come. ;)I'd like to thank everybody who participated on the discussions in the Discord server. This is a product of everone's input.