Fix Cubit STEP import for MagnetSetFromGeometry

[connoramoreno]

A bug prevented Cubit from being able to import STEP files from a MagnetSetFromGeometry object. Specifically, in build_cubit_model, we create a new magnet STEP file to ensure that magnet volumes are ordered and grouped appropriately. This STEP export previously reset the geometry_file attribute before the file was actually exported, which called the MagnetSetFromGeometry setter, which then tries to import said STEP file into CadQuery to resolve the geometry. This led to an error where the STEP file could not be found (understandably).

This PR makes the following changes:

• The MagnetSet.export_step method sets a step_path attribute to differentiate from the original user-set geometry_file attribute
• The MagnetSet.import_geom_cubitmethod uses the step_path attribute if it’s been set, otherwise uses the original geometry_file attribute. The Stellarator.build_cubit_model method will leverage the former workflow, to ensure volumes are ordered appropriately. For meshing, etc., geometry_file will suffice
• MagnetSetFromGeometry will now resolve the geometry only if geometry_file is a STEP file (CUB5 is also allowed)
• Removes import_dir from all cubit_utils functions, since a full path in filename is really all that’s necessary
• Updates syntax according to the previous list item

[connoramoreno]

For some reason, Perform CI Tests is not using the updated code...

[gonuke]

For some reason, Perform CI Tests is not using the updated code...

I think this is the problem: we now (and for some time now) install parastell when we build and push the parastell-ci docker image. The CI tests don't install a new version, but just run tests. I wonder if the tests are using the installed version and not the local code.

Before we were doing pip install, the pytest only had the local code available. We probably need to pip install in the ci tests before running tests.

[gonuke]

Hopefully #267 will fix this…

[gonuke]

I changed #267 to be a PR into this branch.... I reran the test, but not sure if that actually picked up your changes.

[gonuke]

I guess that didn't help ☹️

[connoramoreno]

Based on GitHub's documentation, if I'm understanding correctly, the commit checked out by actions/checkout@v4 is the latest merge commit on the target branch of the PR (main in this case). That would imply that CI doesn't test code changes though, so maybe I'm misunderstanding.

[gonuke]

Trying to understand how this testing is setup

[gonuke]

Wait... why do we go to /opt/parastell/tests to do our testing? That isn't where we checkout the repo... maybe removing that will help?

[connoramoreno]

Where does the repo get checked out? The documentation is unclear to me Seems to be checked out in the PWD.

[connoramoreno]

That said, the ParaStell imports in the test suite are not relative, so I'm not sure the correct version of ParaStell will be used

[gonuke]

more CI testing questions

[gonuke]

Also... I can't figure out what is in /opt/etc/bashrc that is so important?

[connoramoreno]

That may be an artifact of when we put ParaStell on PYTHONPATH explicitly. Maybe unnecessary at this point, unless that's still necessary for Cubit.

[connoramoreno]

This command also activates the appropriate conda environment (see the Dockerfile)

[gonuke]

It's probably the conda activation that is important 👍🏻

[connoramoreno]

We're also still having the issue that we're using up Cubit license seats during CI. When tests fail, /opt/Coreform-Cubit-2025.8/bin/rlm_activate --logout doesn't run, so we don't free up the seat.

[connoramoreno]

@gonuke looks like everything is working now

[gonuke]

Looks like there was actually a bug :) glad testing helped you find it!

[connoramoreno]

Yeah, there was a new bug introduced by this PR that the test wasn't reaching before