Fixed to reflect FLUKA-CERN #677
Conversation
|
Does this mean that this PR is not ready until you get a chance to test that??? |
makeclean
force-pushed
the
fluka-cern
branch
from
6f0a7ef to
55a8a1d
Compare
|
Ok, this is fixed now, and working, a few changes to documentation and this should be good to go. |
|
Does |
|
In previous version of FLUKA, we apply a patch to |
|
No I'll update the documentation accordingly, the executabe assumes
that you will be using a DAGMC file called dagmc.h5m, then there is no
need for the patch and also mimics what OpenMC does for example with
DAGMC files.
…On Tue, 2021-01-12 at 11:13 -0800, Lucas Jacobson wrote:
In previous version of FLUKA, we apply a patch to rfluka.patch in
order to have FLUKA recognize the -d option as specifying the DAGMC
geometry file. However in FLUKA 4.1.0, the -d option is already
reserved for a different purpose.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
When I get some time, ill make some futher changes, but it will allow
building aginst FLUKA-CERN and the other FLUKA
…On Tue, 2021-01-12 at 11:13 -0800, Lucas Jacobson wrote:
In previous version of FLUKA, we apply a patch to rfluka.patch in
order to have FLUKA recognize the -d option as specifying the DAGMC
geometry file. However in FLUKA 4.1.0, the -d option is already
reserved for a different purpose.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Alright, I think this is finally ready for merging. The documentation has been updated, the build is better. A new argument has been added and the patch file is no longer needed. |
|
Looks like a style guide failure, the website lists the old astyle options, what are the current set of style guide checks that should be done? We should update the docs there too. |
|
We moved to |
|
Until then, see here: https://github.com/svalinn/DAGMC/blob/develop/CI/circleci/housekeeping.sh#L23 |
|
@makeclean - we're getting ready for another release. Might be good to include this if we can get the style check working. I'm going to close/reopen to kickstart the CI since we've transitioned to Github actions. |
|
Sorry, but we've also changed the News/Changelog requirement. I'll take care of that for you with a PR to this branch once you've rebased. 😊 |
|
Ping @makeclean for a quick rebase and switch from News => Changelog |
makeclean
force-pushed
the
fluka-cern
branch
from
9666d7b to
b23b353
Compare
|
Time has moved on, and so did - what did need to do to get this into main? |
|
I think the first step is to get CI to run again.... I am not sure why I can't just ask it to rerun the tests? |
|
Revisiting this @makeclean - we have a potential user of this who is interested to see it working. Probably needs a rebase to relaunch testing. |
|
It seems that the next step is to create some test files for CI and see how they work, right? |
|
@makeclean, can you please consider giving this a rebase? |
|
Finally got around to refreshing this :) |
|
Please update the CHANGELOG.rst and run clang-format in the root dir. It seems, windows is not downloading the PyNE sources. |
|
Update the changlog to what? |
|
We generally track our PRs through the changelog file located at I have recently created a PR with these changes on your branch. Please take a look. |
Update changelog file and run clang-format
|
Ok, I think ready for review - I guess the windows build is a common failure? |
|
Sadly, this is the first clear sign of the Windows failure, but it's not your fault... it seems to be related to some change in the underlying Windows runner. Hopefully, we can find a fix quickly.... |
|
I think the windows build issue is now solved by #958. |
Fixes to FluDAG to allow building against the new FLUKA-CERN release. However... there has been a change to how FLUKA is run, originally (effectively hidden within the rfluka script) what happens is
flukahp inputwhere as what used to happen was
flukahp < inputNo big issue, but before there were never any arguments to the fluka executable, and now there are, again no big issue, however this appears to have broken how FluDAG (and FluGG) would be run with a partial FLUKA input file (+ geometry supplied in memory). The subtle change, means there must be another function called which reads the input deck, before the
flukamsubroutine is called, when I get source code it'll be easy to figure out, currently working on getting that, in the mean time im scrabbling around trying to find it.