Improve interface for transport model surrogates that provide fluxes

[theo-brown]

I'm looking to integrate a transport surrogate @lorenzozanisi developed into TORAX.
Similar to QLKNN, it takes in gradients, geometry, etc and produces qi, qe, and pfe (or pfi).
Given many transport models have the same or similar mapping (gradients to fluxes), would there be scope for generalising the transport model interface to facilitate this? For example, currently I would be writing a new make_core_transport function that would largely replicate the existing one for QLKNN, albeit with replacing QualikizInputs and QualikizDynamicRuntimeParams with LorenzoInput and LorenzoDynamicRuntimeParams.

[theo-brown]

In a meeting with @jcitrin, @hamelphi, @theo-brown, @lorenzozanisi, we proposed the following architecture:

• QuasilinearTransportModel(TransportModel) - @hamelphi
  • RuntimeParams
  • DynamicRuntimeParams
  • make_core_transport
  • QuasilinearTransportModelInputs
• qualikiz_inputs.py
  • QuaLiKizInputs(QuasilinearTransportModelInputs)
  • prepare_qualikiz_inputs
• QLKNN(QuasilinearTransportModel)
  • RuntimeParams
  • DynamicRuntimeParams
• QuaLiKiz(QuasilinearTransportModel)
  • RuntimeParams
  • DynamicRuntimeParams
• tglf_inputs.py - @theo-brown https://github.com/theo-brown/torax/tree/tglf-surrogate
  • TGLFInputs(QuasilinearTransportModelInputs)
  • prepare_tglf_inputs
• TGLF(QuasilinearTransportModel) - @lorenzozanisi ?
  • RuntimeParams
  • DynamicRuntimeParams
• TGLFNN(QuasilinearTransportModel)
  • RuntimeParams
  • DynamicRuntimeParams

Additionally, there is code in the qualikiz_inputs that can be moved across to physics / a common function, e.g. Ati, Ate, etc can all be put in a function that takes in a particular choice of radial coordinate and normalising factor etc - @jcitrin

Separately, we noticed that lam_ei, tau_ei, etc can all be extracted and cleaned up in physics. - @jcitrin

make_core_transport should depend on a specific reference length, rather than Rmaj/Rmin necessarily. @jcitrin

Potentially prepare_XXX_inputs could just be a classmethod of the XXXInputs class.

We also are not sure whether we need to replicate this pattern:

torax/torax/transport_model/qlknn_wrapper.py

Line 150 in 4525532

class QLKNNRuntimeConfigInputs:

[theo-brown]

For starters, QuasilinearTransportModelInputs should store all the variables used in make_core_transport, and computation should be done in the subclasses