Common proton charge loader

[jl-wynen]

This moves the proton charge loader provider from ESSimaging into ESSreduce. I changed the parameters a little to make it fit into the workflow more neatly (ProtonCharge is not a Component and so shouldn't have a NeXusName.)

I did not generalise the normalisation because of #551.

Note that ESSreflectometry calls this ProtonCurrent and has its own providers. Should I rename it and use the same domain type? Or should we wait until we have an actual ESTIA NeXus loader for experimental files?

[SimonHeybrock]

Note that ESSreflectometry calls this ProtonCurrent and has its own providers. Should I rename it and use the same domain type? Or should we wait until we have an actual ESTIA NeXus loader for experimental files?

If the ProtonCurrent is a charge it should be renamed, if it is actually a current then the workflow should be changed, either to compute current from charge, or use charge directly?

[SimonHeybrock]

This is confusing. The accelerator has no neutrons. Production of what?

[jl-wynen]

But the accelerator is used to produce neutrons. I took the name from the nexus files. The group contains

        grp   beam_cycle_id/
        grp   beam_destination/
        grp   beam_destination_mode/
        grp   beam_mode/
        grp   beam_present/
        grp   beam_pulse_end_event_counter/
        grp   beam_pulse_end_event_id/
        grp   beam_pulse_length/
        grp   beam_pulse_start_event_counter/
        grp   beam_state/
        grp   cryo_tt_82025_temperature/
        grp   cryo_tt_82027_temperature/
        grp   cryo_tt_82029_temperature/
        grp   cryo_tt_82031_temperature/
        grp   cryo_tt_82033_temperature/
        grp   cycle_start_event_counter/
        grp   data_buffer_sent_offset/
() 16B  utf-8 depends_on                     .
        grp   flat_top_current/
        grp   fsm_machine_active/
        grp   high_beta_flat_top_current/
        grp   high_beta_pulse_charge/
        grp   high_beta_pulse_width/
        grp   intended_proton_current/
        grp   intended_proton_energy/
() 16B  utf-8 name                           accelerator
        grp   ni_acq_start_event_counter/
        grp   ni_sync_event_counter/
() 16B  utf-8 probe                          proton
        grp   pulse_charge/
        grp   pulse_width/
        grp   raster_pattern/
() 16B  utf-8 target_material                W
        grp   target_segment/
        grp   transformations/
() 16B  utf-8 type                           Spallation Neutron Source

[SimonHeybrock]

So you say it corresponds the group name in NeXus? That's a good convention then.

[jl-wynen]

It does approximately, the name is 'neutron_prod_info'.

[jl-wynen]

Note that ESSreflectometry calls this ProtonCurrent and has its own providers. Should I rename it and use the same domain type? Or should we wait until we have an actual ESTIA NeXus loader for experimental files?

If the ProtonCurrent is a charge it should be renamed, if it is actually a current then the workflow should be changed, either to compute current from charge, or use charge directly?

ESS NeXus files only encode the charge each second. You could convert that to a current but I doubt that anyone would do that. In reflectometry, the 'proton current' is currently dimensionless. So it is not clear what it represents. @jokasimr can you clarify?

[jokasimr]

ESS NeXus files only encode the charge each second. You could convert that to a current but I doubt that anyone would do that. In reflectometry, the 'proton current' is currently dimensionless. So it is not clear what it represents. @jokasimr can you clarify?

1. It's not correct to say the proton current is dimensionless in reflectometry. The proton current correction in reflectometry is agnostic to the unit of the proton current quantity.

2. It's true that there are examples in the docs or maybe in the tests where the proton current is assigned a dummy value that is dimensionless.

[jl-wynen]

ESS NeXus files only encode the charge each second. You could convert that to a current but I doubt that anyone would do that. In reflectometry, the 'proton current' is currently dimensionless. So it is not clear what it represents. @jokasimr can you clarify?

1. It's not correct to say the `proton current` is dimensionless in reflectometry. The proton current correction in reflectometry is agnostic to the unit of the proton current quantity.

2. It's true that there are examples in the docs or maybe in the tests where the proton current is assigned a dummy value that is dimensionless.

Fine, but what I meant is that I can't tell based on the code what unit it should have. Should it be A or C? If you say it's agnostic, then can we just fix it to C and call it 'proton charge'?

[jokasimr]

I don't mind, either "_current" or "_charge" works for me. But it might make sense to use the same convention that ECDC uses when they store the proton current in the nexus files.

[SimonHeybrock]

@jokasimr Can you review the reflectometry-specific changes here? Thanks!

[jokasimr]

Looks good to me 👍