Change iteration variables to prevent negative dimension of space inside cable (m)

[jonmaddock]

In GitLab by @mkovari on Dec 4, 2018, 15:29

Previously I adjusted the TF code to prevent negative winding pack thickness (#514). We also often get errors due to negative values of leni (the width of the space inside the cable). This is because leni is derived by subtraction:

leni = conductor_width - 2.0D0*thwcndut

It would be nice to eliminate this problem by building the winding pack up from the inside to avoid subtractions.

@jmorris-uk @ajpearcey @stuartmuldrew @Hlux

[jonmaddock]

In GitLab by @Hlux on Dec 4, 2018, 15:31

Yes, sounds reasonable to me! Please implement.

[jonmaddock]

In GitLab by @ajpearcey on Dec 6, 2018, 18:50

I have implemented a possible solution to this issue. Previously the the internal copper core and strand in the cable would stay at a constant size while the size of the conductor was optimised. This has now been updated so that these parts of the croco model scale with the geometry of the conductor. While this does not explicitly rule out negative values of variables like leni, since the implementation of this the output no longer gives negative values for leni. Although this needs to be checked more robustly.

There are three REBCO strand input parameters which are now no longer just defined in the input file: tape_width, croco_od and croco_id

In sctfcoil.f90 the subroutine supercon_croco now defines the outer diameter of the croco as

croco_od = conductor_width / 3.0d0 - thwcndut * ( 2.0d0 / 3.0d0 )

Noting that we are still keeping this troublesome substitution.

While the other variables are used in superconductors.f90 in the subroutine croco and are scaled using ratio of the "old" and "new" croco_od.

! Define the scaling factor for the input REBCO variable
! Ratio of new croco outer diameter and fixed base line value 
scaling = croco_od / 10.4d-3

The new scaling factor is included in the instances of using tape_width and croco_id when computing output variables.

[jonmaddock]

In GitLab by @wg7580 on Jul 20, 2022, 09:10

closed

[mkovari]

See discussion #2923.