Considering an attempt at wrapping with numpy.f2py

[SimonBiggs]

Hi @ftessier,

I am interested in attempting wrapping the core physics subroutines within egsnrc.mortran with numpy.f2py. Also, hoping to be able to set up cibuildwheel so that the mortran --> fortran --> built + wrapped in python is all within a readily pip installable wheel for each OS.

Is this something you would be interested in having me create PRs into the EGSnrc repo itself? Or would you prefer I create a separate repo to do this? Either way is fine for me, more just wanting to get a feel for your preference before diving in.

Cheers,
Simon

[ftessier]

Great and original idea! For shure I am interested in a proof of principle to see how this works. For a long while I have wanted a .deb or .rpm package, linux snap or what have you to simplify EGSnrc installation and integrate it into the standard software installation method. If numpy.f2py works, then we can aslo contemplate writing all the simulation management side of things in python, which would be so much easier. Best if you work on a branch in your repo. Initiate a pull request any time and update as you go (or else let me know which branch in your repo you are working on, and I can follow it there!).

[SimonBiggs]

If numpy.f2py works, then we can aslo contemplate writing all the simulation management side of things in python, which would be so much easier. Best if you work on a branch in your repo.

Yeah, that would be nice.

Initiate a pull request any time and update as you go

Yup, will do. I'll mark it as draft. Would you be okay if I make a directory HEN_HOUSE/python? I find code review works much neater in bite sized pieces. Would you be okay to do iterative PRs? That would mean the contents of HEN_HOUSE/python that are merged within the develop branch might not actually be working initially.

[ftessier]

Mark it with "WIP" (work in progress) somewhere in the title (some git tools ignore "wip" PR, so that is useful). Start from the current develop, and do whatever you want in the PR, adding directories, etc., but always push to the same branch, which updates the same PR, which makes it easy to track progress. Ideally, commit often and in logical units, but don't worry too much about that, we can reorganize the branch completely before merging into develop eventually...

[ftessier]

Alternatively, if you prefer working on it more privately for now, just work on a branch in your fork, and open a PR when you are ready to share. In the mean time, if you want us to look at it, we can clone your branch and discuss it offline. I favor doing this through a PR, since other contributors might jump in and further ignite development of your idea.

[SimonBiggs]

I'll go the PR route, quite keen on iterative feedback.