Fix a bug in Nieves CCQE hadron tensor

[LiangLiu212]

Nieves CCQE model uses ( not pre-calculated hadron tensor ) hadron tensor in the rest frame of initial nucleon and q should be in z direction. Now we use coordinate system in the rest frame of nucleus. We need to do boost and rotation to do the transfermation.

[idkakorin]

Dear Liang Liu,

thanks for the careful look at the implementation — this is an important point to clarify.

Just to avoid a possible misunderstanding, regarding the Nieves CCQE model as it is implemented here:

1. The Nieves CCQE model does not rely on a pre-calculated hadron tensor. The hadronic tensor is computed on the fly for each kinematic point.

2. In the hadronic tensor calculation, the coordinate system with \vec{q} aligned along the z-axis is already used. This can be seen directly in the code (e.g. around line 946), where the corresponding quantities are explicitly constructed in that frame.

So no additional boost or rotation from the nucleus rest frame is required for this part of the calculation.

Thanks again for raising this — happy to clarify further if something remains unclear.

[LiangLiu212]

Hi, Igor,

Thank you for your comments.

1. For the pre-calculated, I mean it is in an expanded expression instead of using Dirac gamma matrices in the code.

2. We need to boost the frame to nucleon rest frame. We never done it before. I know the code in line 946. We just need a additional rotation after boost.

I'm happy to give a presentation in GENIE core meeting. I can show more details.

Best!

Liang

[idkakorin]

Hi Liang Liu,

I think the core issue here is the wording “pre-calculated hadron tensor”.

In GENIE, several nuclear models indeed rely on hadronic tensors that are pre-computed and tabulated as functions of kinematic variables in a specific reference frame, and then interpolated at runtime. However, this is not the case for the Nieves CCQE model.

In the Nieves implementation, the hadronic tensor is evaluated dynamically for each event, using explicit analytical expressions for the tensor components. These expressions are implemented in a reduced (expanded) form, expressed directly in terms of four-vectors and structure functions; they are never derived from explicit Dirac traces and are not pre-calculated, stored, or reused across events

So calling this a “pre-calculated hadron tensor” is misleading in the GENIE context, where that term has a very specific meaning and refers to a different class of implementations.

This distinction is important, because it also explains why no additional boost/rotation step is required here: the analytical expressions are already derived under the appropriate frame assumptions.

Best!

Igor

[LiangLiu212]

Hi Igor,

Sorry again for the misleading wording. What I meant is that the Nieves model is formulated in the rest frame of the initial nucleon, not in the rest frame of the initial nucleus.

Best regards,
Liang

[idkakorin]

Hi Liang,

Today, during the NIUWG meeting, this behavior was explicitly highlighted and discussed as a potential issue in a talk by Gray Putnam, including discussion during the presentation. Since this interpretation has already reached a broader audience, it seemed important to clarify the actual implementation details and document the correct treatment in order to avoid further confusion.

I would like to clarify where the frame conventions are already handled and what is actually being treated as the “nucleus” in the GENIE implementation.

First, the transformation to what is effectively the nucleus rest frame is already performed upstream in XSec() (around lines 236–270). By the time LmunuAnumu() is called, all kinematic quantities are already constructed consistently within that convention, so adding an additional boost/rotation at this stage is redundant.

Second, what GENIE refers to as the “nucleus momentum” in this context is, by construction, the momentum of the struck nucleon. This is explicit in the code: in XSec() around line 108, the on-shell energy is constructed directly from the momentum of target.HitNucP4(). This is an intentional design choice, reflecting the GENIE philosophy of treating the nucleus as an ensemble of bound nucleons with Fermi motion and performing the interaction on a single nucleon. This differs from the fully averaged LFG treatment used in the original Nieves paper, but it is not an inconsistency of the current code.

Because of these two points, introducing an explicit boost to the nucleon rest frame inside the Nieves tensor evaluation is not compatible with the current structure and risks double-applying frame assumptions that are already accounted for earlier in the calculation.

I encountered this issue several years ago while implementing nucleon polarization effects, which required a systematic reworking of the Nieves model. In that work, the model was largely rewritten to follow the original formalism more closely while also improving performance, with explicit support for both LFG and RFG descriptions and a switch to compare against the original Dytman-based implementation. That implementation already resolves the frame and averaging issues consistently and does not require any additional kinematic corrections. A reference implementation is available here:
https://github.com/idkakorin/Generator/tree/final_charged_lepton_polarization

Best regards,
Igor

[LiangLiu212]

Hi, @idkakorin, I message you at GENIE slack channel. are you available for a short meeting now?