Issue in eq.tokamak['CS'].control parameters

[geekygiks]

Hi, I am running latest version of freegsnke with experimental coil currents parameters in inverse mode in fig 1 and fig 2.

In fig 1, I have set eq.tokamak['CS'].control = "True" and my CS coil current changes accordingly, whereas fixing eq.tokamak['CS'].control = "False" my CS coil is dropped to 0.0 as shown in fig 2. All the other parameters are same. As per my understanding, fixing the parameter as "False" should not change the CS coil current.

Request you to please look into it and guide further.
Fig 1. eq.tokamak['CS'].control = "True"

Fig 2. eq.tokamak['CS'].control = "False"

[kpentland]

Hi there,

Thanks for spotting this. Very strange this happens.

Instead of setting your coil currents as you currently do, can you try using this method in the tokamak class (it's more robust and we would discourage changing the coil dictionaries directly):

eq.tokamak.set_coil_current('CS', -8.57e7) eq.tokamak['CS'].control = False

Let me know if this helps (or not)!

[konerr]

On a similar note, is there a way to change the solenoid (or coil) position without changing the dictionaries?

[geekygiks]

Thanks for prompt reply. The code breaks while doing the inverse calculation. I have tried it multiple times

freegsnke version used

Name: freegsnke
Version: 2.0
Summary: FreeGSNKE: A Python code for evolutive free-boundary tokamak plasma equilibrium simulations
Home-page: https://github.com/FusionComputingLab/freegsnke
Author: The FreeGSNKE Developers
Author-email:
License:
Location: /usr/local/lib/python3.12/dist-packages
Requires: deepdiff, h5py, matplotlib, notebook, numpy, scipy
Required-by:

[kpentland]

On a similar note, is there a way to change the solenoid (or coil) position without changing the dictionaries?

At the moment no, you need to change the dictionaries and re-build the machine (as the Green's matrices need to be updated). Thanks.

[kpentland]

Thanks for prompt reply. The code breaks while doing the inverse calculation. I have tried it multiple times

Please can you make the change for when you set all of the coil currents please? The old version shouldn't be used anymore. You can, however, set the control=True/False in the way you currently do it. Please try again and if the error persists we can take a closer look. Thanks.

[geekygiks]

Thanks for prompt reply. The code breaks while doing the inverse calculation. I have tried it multiple times

Please can you make the change for when you set all of the coil currents please? The old version shouldn't be used anymore. You can, however, set the control=True/False in the way you currently do it. Please try again and if the error persists we can take a closer look. Thanks.

Thanks.

the error still persists. I am using 2.0 version.

[geekygiks]

I have looked into the code for the error and found that rel_change_full is not returned when the solution fails to find O point. I have randomly initiallized it to rel_change_full=0 --> line 906 where it fails in GStaticsolver.py

    # prepare all green functions needed by the current optimizations
    constrain.prepare_for_solve(eq)

    check_equilibrium = False
    try:
        ** rel_change_full=0**   --> included this 
        GS_residual = self.F_function(
            tokamak_psi=self.tokamak_psi.reshape(-1),
            plasma_psi=eq.plasma_psi.reshape(-1),
            profiles=profiles,
        )
        if verbose:
            print("Initial guess for plasma_psi successful, residual found.")
        rel_change_full, del_psi = self.relative_del_residual(
            GS_residual, eq.plasma_psi
        )

There is another issues we have been facing since previous versions, especially in Jtor.py for cases where I_R=0 or I_R=1 it fails, I have try/exception to bypass the issues.

L = self.Ip / I_R - LBeta0 * (IR / I_R - 1)

Both these modifications helped me run my code and I am getting expected results.

[kpentland]

Hi,

Thanks for trying this fix, are you able to create a branch and submit a PR so we can merge this in?

As for the second problem, please open another issue and we can look into it!

Thanks

[theo-brown]

I think there's some duplication here with #32 and #21