Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(fourc_mc_tests): convert dat to yaml #141

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

gilrrei
Copy link
Member

@gilrrei gilrrei commented Feb 26, 2025

Description and Context

Convert one of the 4C tests types to yaml. The other one can't be transformed since the external geometry still relies on dat

Related Issues and Pull Requests

  • Closes
  • Blocks
  • Is blocked by
  • Follows
  • Precedes
  • Related to
  • Part of
  • Composed of

How Has This Been Tested?

Checklist

  • My commit messages mention the appropriate issue numbers (advised but optional).
  • I mention the appropriate issue numbers in this PR.
  • I updated documentation where necessary.
  • I have added tests to cover my changes.

Additional Information

Interested Parties

Possible reviewers:

Other interested parties:

@gilrrei gilrrei force-pushed the use_yaml_file_for_4C_test branch from 9aa3d66 to 02ac723 Compare February 26, 2025 12:09
@maxdinkel
Copy link
Member

Can we delete the corresponding .dat file?

@gilrrei
Copy link
Member Author

gilrrei commented Feb 27, 2025

Can we delete the corresponding .dat file?

Nope, because one of the external geometry tests (I think for the ensight postprocessor) is based on the dat file. The good news is that @amgebauer is working on lnmmeshio to introduce full yaml support such that later on the entire external geometry will become much much easier

@maxdinkel
Copy link
Member

Can we delete the corresponding .dat file?

Nope, because one of the external geometry tests (I think for the ensight postprocessor) is based on the dat file. The good news is that @amgebauer is working on lnmmeshio to introduce full yaml support such that later on the entire external geometry will become much much easier

But then I would propose to wait for the implementation in lnmmeshio. Otherwise we will have to maintain an extra input file.

@gilrrei
Copy link
Member Author

gilrrei commented Feb 27, 2025

But then I would propose to wait for the implementation in lnmmeshio. Otherwise we will have to maintain an extra input file.

I don't know how soon somebody will change the code to lnmmeshio, but I think it is important to start testing yaml files for 4C as soon as possible is important. If you oppose maintaining a single additional file is too much we can close this PR.

@maxdinkel
Copy link
Member

But then I would propose to wait for the implementation in lnmmeshio. Otherwise we will have to maintain an extra input file.

I don't know how soon somebody will change the code to lnmmeshio, but I think it is important to start testing yaml files for 4C as soon as possible is important. If you oppose maintaining a single additional file is too much we can close this PR.

I don't have a strong opinion on this. If you think it's important to test it with .yml input, we can also maintain an extra file.

Copy link
Member

@leahaeusel leahaeusel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tend to agree with @gilrrei that we should start testing yaml files for 4C.

Comment on lines +2 to +3
This is a simple test that tests the extrapolation of stressees from Gauss points to nodes for a
hex8 discretization tested date: 19.12.2024
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This is a simple test that tests the extrapolation of stressees from Gauss points to nodes for a
hex8 discretization tested date: 19.12.2024
This is a simple test that tests the extrapolation of stresses from Gauss points to nodes for a
hex8 discretization. Tested date: 19.12.2024

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the .4C in the file name really necessary if the file is already in a folder named fourc?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants