combine coils

[TimSlendebroek]

torrin's pf_active file

example run:

ini,act = FUSE.case_parameters(:ITER;init_from=:ods);

ini.equilibrium.boundary_from = :MXH_params
R0 = 6.2
Z0 = 0.4
ϵ = 0.32
κ = 1.8
δ = 0.485
ζ = -0.09583
ini.equilibrium.MXH_params = [
    R0, Z0, ϵ, κ, 0.00337,
    0.15912, -0.05842, -0.04573, 0.00694, 0.00614, 0.00183,
    asin(δ), -ζ, -0.05597, -0.01655, 0.00204, 0.00306]

dd = IMAS.dd()
FUSE.init(dd,ini,act);
pop!(dd.pf_active.coil)
pop!(dd.pf_active.coil)
FUSE.ActorEquilibrium(dd,act;ip_from=:pulse_schedule)
# FUSE.ActorPFactive(dd,act;do_plot=true);
p = plot(dd.equilibrium;cx=true)
plot!(dd.build)
display(plot!(dd.pf_active))
#    

[torrinba]

FUSE is probably better off without having the vertical stabilization coils in there by default since they shouldn't be used for shaping, but maybe you want to keep them for other applications?

[TimSlendebroek]

@orso82 can you tag these vertical stabilization coils as :stability coil instead of :shaping ?

[orso82]

yeah, right now FUSE can automatically differentiate and tags coils that are used for :shaping and/or :flux. We need to think of a way to automatically tag vertical stability coils... perhaps the combination of being small, of :annulus geometry, and with few turns?

[torrinba]

The annulus type is probably particular to how ITER describes these and not universal for VS coils. A small number of turns could be a better way to distinguish them, but may not be universal either. A combination of that and the distance to the plasma (or center of the vessel) on the outboard side could be that

[bclyons12]

I think trying to tag that automatically will be tough. DIII-D, for example, uses the same coils for shaping and stability. You probably just want them user-specified and you have a separate actor that operates on the vertical-stability coils.

[orso82]

@torrinba can you please explain what has changed with this pf_active for ITER?

Looking at the diff https://github.com/ProjectTorreyPines/FUSE.jl/pull/525/files I see a whole bunch of fields being deleted.

[torrinba]

The primary change here is to link the middle CS coils (CS1U and CS1L, now separate elements in CS1). This is not part of ITER's MD, but was communicated to us by @anandhimank as the way the coils will be installed

Since that changes the number and names of pf_active.coil it messes up the circuit and other fields. Rather than going in and trying to fix all of those, I just deleted them. My understanding was that the coils are all that FUSE is using. It should be possible to fix the others when combining the coils, but I don't have any experience with those entries so I'm not sure I would get it all correct.

[orso82]

Rather than hacking this in, we should support how IMAS defines the power-supply of the coils. This will be important for replicating DIII-D results, where the patch-panel links currents in different coils. Thoughts?

[torrinba]

For sure, if there is a more correct solution for how the coils are controlled either with the circuit or supply entries that would be a better way to go (assuming the MD has that correct). I don't understand what the difference between 2 separate coil entries with the same circuit/supply or 2 elements in the same coil would be, but I agree that we should follow whatever would be most correct. Please help set this up in FUSE

I don't think any of that is setup for DIII-D with the omas machine mappings though so further work would be required there as well

[orso82]

@torrinba the way I understand it, circuit links supply to coil. To begin with, I think all we care about is circuit[:].connections to define what coils have the same current.

Bringing in @bclyons12 into the conversation.

Here is what the data structure looks like

[torrinba]

The latest ITER MD, defines 14 coils, 8 circuits, and 14 supplies in the pf_active IDS. So I'm not sure that works out as simply as we're hoping, but you're probably correct it should be used to control the coils. Hopefully someone can figure that out or explain it to us

Here's the HDF5 ODS version directly from ITER: (only zipped to allow the GitHub upload)
pf_active_ods.zip

[orso82]

ping @anandhimank

[anandhimank]

The DINA scenario given to me from the ITER PCS group assume the following: Total of 14 coils named, 'CS3U', 'CS2U','CS1U', 'CS1L', 'CS2L', 'CS3L', 'PF1 ', 'PF2 ', 'PF3 ', 'PF4 ', 'PF5 ', 'PF6 ', 'VS3U', 'VS3L' with the circuit connections as follows: [1 2 3 3 4 5 6 7 8 9 10 11 -12 12], meaning 'CS1U', 'CS1L', are in series and 'VS3U', 'VS3L' are in anti-series. I am also attaching the data file, you may want to take a look at the CS/PF coil currents and Voltages for more details in the excel file
data_with_eqdsk.xlsx

[orso82]

@bclyons12 we now give a list of coils to VaccumFields, and all those are treated as indepedent.

I see three ways forward.

1. we have VacuumFields accept also a circuit's vector
2. we just pass the whole pf_active to VaccumFields and have the circuit's logic implemented there
3. we build a new AbstractCoil type that handles coils connections internally, leaving VacuumFields untouched
   What do you think?

[bclyons12]

I think 2 or 3 makes the most sense. Either we work with the dd directly and parse the information from there (as we already do for coils with elements) or we make a new AbstractCoil. I assume that the key component here is that the coils/turn is constant across the coils.

[orso82]

I am reluctant to merge this PR, since I don't think combining coils in the data structure is the right way to go.

As we think about how to best implement the circuits logic in VacuumFields, I'd suggest that this hack is done when the DatabaseGenerator is run. @TimSlendebroek could you please generalize the DatabaseGenerator study to accept a user-defined function, which then @torrinba can use to hack the merged coil configuration for his purposes?