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

Full model DAGMC faceting via CAD-to-DAGMC #180

Open
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

connoramoreno
Copy link
Collaborator

@connoramoreno connoramoreno commented Dec 12, 2024

This branch adds support for a fully open-source, freely available DAGMC faceting workflow via CAD-to-DAGMC. This workflow is implemented as an alternative to the Cubit DAGMC faceting workflow.

Changes included in this branch:

  • Introduces a new Stellarator.export_cad_to_dagmc method to automate DAGMC model generation via CAD-to-DAGMC and adds it to test and example scripts
  • Renames the Stellarator.export_dagmc method, which generates DAGMC models via Cubit, to Stellarator.export_cf_dagmc and updates syntax in test and example scripts
  • Removes the InVesselBuild.export_cad_to_dagmc method as it is made redundant by the Stellarator.export_cad_to_dagmc method and removes it from test and example scripts
  • Modifies the magnet modeling workflow to store CAD solids in the MagnetSet.coil_solids parameter for future reference

It should be noted that the CAD-to-DAGMC routine used here enforces that imprinting is skipped, since we have determined based on the way we create geometry that imprinting is unnecessary. It was found that CAD-to-DAGMC's imprinting routine was computationally expensive and required an unreasonable amount of memory for our geometries. Skipping this routine alleviates this computational cost and the meshing is performed in seconds.

@connoramoreno connoramoreno marked this pull request as draft December 12, 2024 22:43
@connoramoreno connoramoreno marked this pull request as ready for review January 3, 2025 19:27
@connoramoreno
Copy link
Collaborator Author

It should be noted that the "Regular CI testing for parastell / Perform CI Tests" workflow is failing because it is not pulling the Docker image corresponding to this branch

@connoramoreno
Copy link
Collaborator Author

@bquan0, do you know how to fix the issue mentioned in the above comment, concerning the proper image tag being used?

@bquan0
Copy link
Collaborator

bquan0 commented Jan 3, 2025

It's because of this line. container: ghcr.io/svalinn/parastell-ci means it always pulls the latest image.
It needs some logic similar to this line in docker_publish.yml where it adds an extra tag if it's not on the main branch.

@connoramoreno
Copy link
Collaborator Author

I figured as much! Just unsure how to go about retrieving the proper tag. Would it be done similarly to this line?

@bquan0
Copy link
Collaborator

bquan0 commented Jan 3, 2025

I think you would have to run an extra job before test-dependency-img that echoes the tag to an output, like in line 46, then use the output in container: like in line 62. This is because ENV variables can't be used in container:, I think.

@connoramoreno
Copy link
Collaborator Author

Since "Build & publish Docker image for ParaStell CI / Test CI Image" runs our test suite when we've made changes to any file affecting our Docker image, I'm going to add a condition to "Regular CI testing for parastell / Perform CI Tests" that will prevent its execution (returning the "Success" status) should any of those aforementioned files be modified. In effect, this change will make it such that our CI testing will defer to "Build & publish Docker image for ParaStell CI / Test CI Image" to test the code under the condition that the Docker image has been modified.

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.

2 participants