TF variables naming conventions

[jonmaddock]

In GitLab by @skahn on Sep 29, 2020, 11:47

Description

Dear all here is a list of varible names I find vague and confusing and proposal to for replacement:

• [ ] Variable change

Old	proposal	description
thwcndut	t_turn_jack	TF coil conduit case thickness (m) (iteration variable 58)
tinstf	dl_tf_wp_ins	Ground WP insulation thickness (m)
thkcas	dl_tf_case_nose	inboard TF coil case outer (non-plasma side) thickness (m) (iteration variable 57)
casths	dl_tf_case_lat	inboard TF coil sidewall case thickness (m) (calculated for stellarators)
casths_fraction	f_dl_tf_case_lat	Inboard TF coil sidewall case thickness as a fraction of tftort
casthi	dl_tf_case_plas	Inboard TF coil case plasma side thickness (m) (calculated for stellarators)
casthi_fraction	f_dr_tf_case_plas	inboard TF coil case plasma side thickness as a fraction of tfcth
tfthko	dr_tf_outboard	TF coil conduit case thickness (m) (iteration variable 58)

• [ ] The use of t for the turn thicknesses
  The use of t in the first might be a little confusing given the fact it can be interpreted as a temperature. However, this is used to be consistent with the other WP turn level thicknesses naming conventions, such as t_conductor, t_turn etc..

• [ ] turn thicknesses without coils specification
  I think t_turn, that applies only to the TF coil, is a bit confusing as there is also CS and probably PF turns with potentially sizes. It might be clearer to use t_tf_turn for instance

• [ ] *Are `_is_fractionvariables really necessary ?** Concenringcasthi_is_fractionandcasths_is_fraction, I am not sure we really need them. We can just setcasthi_fractionandcasths_fractionto -1 and their boundaries between 0 and 1, and use thecasthi/casths` values if the fractions are -1 and use the fractions otherwise.

Ref: @jmorris-uk, @stuartmuldrew

Best regards
Seb

[jonmaddock]

In GitLab by @jmorris-uk on Oct 9, 2020, 15:23

t_ and dl_ should be dt_ for theta direction

[jonmaddock]

In GitLab by @wg7580 on Jul 20, 2022, 08:31

@skahn has this been implemented or is it something that still needs looking in to?

[chris-ashe]

This issue should be addressed at a later stage of Pythonisation when then new code layout has been decided. Blocked by #2893 It does not serve any benefit to do it at this time except to hinder.