MF2 and MF32 use similar objects (also with a similar interface), e.g. the Resonanceparameters in MF2 LRF7 and MF32 LCOMP1 LRF7 and LCOMP2 LRF7. Such things happen quite often in the ENDF format (e.g. MF4 and MF14, MF6 and MF26, etc.).
Wrapper function name clashes occur in the linking process of the python bindings when a situation like this pops up. To solve this, wrapper function are now being wrapped into the appropriate namespaces associated to the proper file. Since MF2 was implemented long before this became standard practice, this section does not have this namespace wrapping.
In order to avoid future MF32 namespace conflicts, the PR puts all MF2 wrapper functions inside an mf2 namespace. This has no effect on the actual python interface so no tests were updated.
MF2 and MF32 use similar objects (also with a similar interface), e.g. the Resonanceparameters in MF2 LRF7 and MF32 LCOMP1 LRF7 and LCOMP2 LRF7. Such things happen quite often in the ENDF format (e.g. MF4 and MF14, MF6 and MF26, etc.).
Wrapper function name clashes occur in the linking process of the python bindings when a situation like this pops up. To solve this, wrapper function are now being wrapped into the appropriate namespaces associated to the proper file. Since MF2 was implemented long before this became standard practice, this section does not have this namespace wrapping.
In order to avoid future MF32 namespace conflicts, the PR puts all MF2 wrapper functions inside an mf2 namespace. This has no effect on the actual python interface so no tests were updated.