(post deleted at the request of the author)
Dear Abdul,
python2c.py script located in src β tools
I presume you meanfortran2c.py(since anyway you use it on mgdraw.f).
- For now, you can use the conversion script on the include files (
*.inc):
python src/tools/fortran2c.py include/genstk.inc
This will make all shared Fortran variables (ie, all variables in the .inc file) directly available from C. The equivalent .h file is fully created, with all variables declared in C and mapped (in memory) to the Fortran ones. Hence, you do not need to go through what is mentioned in How to access FORTRAN COMMON blocks from C/C++ , since this is already done by the script. Note that this mapping is bi-directional: any change to a COMMON variable in the Fortran side will be directly seen from C, and vice-versa. This is because the variables versions defined in the .inc(Fortran version) and .h (C version) both point to the same memory address.
Note that if you had to use the COMMON arrays translated to C as-is, this would be quite cumbersome, because you would still have to worry about the Fortran start index (which of course is not always 1), and the index discrepancy with C (starts from 0 instead of 1). To overcome this limitation, in addition to the βrawβ translation of data containers, I have made so that the script automatically creates getters/setters (still placed in the .h), so that each variable in a data container can be accessed easily from C. For example, CXR(i) (in Fortran) just becomes genstk::cxr(i) (in C).
- You can use the conversion script on source file (
.f), but for now it will only return an empty skeleton, with only the functions signatures, and list of.hto include:
python src/tools/fortran2c.py src/user/mgdraw.f
I have actually recently extended fortran2c.py so that it also assists source translation. It will be available in the next v4 release. It notably assists with the COMMON variable identification (you do not need to doCXR(i) -> genstk::cxr(i) yourself, it automatically identifies which COMMON the variable belongs to). I have not included keywords translation because it was straightforward (I have it locally), but could do, so that the entire source can be automatically converted, just with the script and in a reliable way.
-
Overall, while technically possible to do, I would not really recommend a user to write the user routines in a language that is different from the codebase which they are interacting with, because this will add sources of error. Since the v4 COMMONs are in Fortran, I would recommend that you use Fortran. While instead, the next generation of FLUKA, called v5, is in C++, and there it makes more sense to use C or C++ to customize the code to your needs.
Hope this helps,
Gabrielle