Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

De-cluttering Directory structure #5

Open
SAnsell opened this issue Feb 3, 2014 · 3 comments
Open

De-cluttering Directory structure #5

SAnsell opened this issue Feb 3, 2014 · 3 comments

Comments

@SAnsell
Copy link
Owner

SAnsell commented Feb 3, 2014

The current top directory is a mess. Could do with a set of sub-directories. Build / General / MCNPX come to mind. Suggestions?

@SAnsell SAnsell closed this as completed Feb 3, 2014
@SAnsell SAnsell reopened this Feb 3, 2014
@kbat
Copy link
Collaborator

kbat commented Feb 3, 2014

My major suggestion regarding the folder structure is to separate the system files and the user source code, so that the later could live somewhere outside the CombLayer folder. I think this separation is logical and common for many software projects and reduces amount of mess in the folder structure.
Of course even now a user can separate his own code, but this requires him to write his own Makefile, which is not straightforward for some users.

@SAnsell
Copy link
Owner Author

SAnsell commented Feb 3, 2014

Thanks for the comment. I think you are 100% correct. The lack of
separation starting to really annoy me. I would like all the model specific
stuff out of the codebase into a kind of examples sub-directory. My plan is
something like models / construction / Monte Carlo / Support.

Model: Clearly stuff only for one model , e.g. makeEss.cxx
Construction : Stuff that builds object but can be/are used in multiple
places, e.g. pipeLine.cxx / SupportPipe.cxx/ CylPreMod.cxx
Monte-Carlo : Transport, volumes, tallies, variances , weights etc Code
that is specific to most Mcnpx models but not to a particular model.
Support : Code like makeString, polynominal, Vec3D. Code that general
enough to be used in other projects. My simple test is that if I was given
the .cxx and .h files, I would not know that if came from a Monte-Carlo
modelling code.

Test is a mess and should just be split into test directories, maybe just
testModel, testConstruction etc.

I will start a new branch with my initial attempts. Feel free to
comment/change modify etc.

The ideas above are not set in stone, so if you think I have missed
something, there is a better way please let me know.

p.p.s The adding of a new directory is another mess....

On 3 February 2014 09:23, Konstantin Batkov [email protected]:

My major suggestion regarding the folder structure is to separate the
system files and the user source code, so that the later could live
somewhere outside the CombLayer folder. I think this separation is logical
and common for many software projects and reduces amount of mess in the
folder structure.
Of course even now a user can separate his own code, but this requires him
to write his own Makefile, which is not straightforward for some users.

Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-33934861
.

@milocco
Copy link

milocco commented Feb 3, 2014

Hi all,

I also agree that it would be better to separate off what specific to a
model and the general stuff...
In particular, what would go into Monte-Carlo directory for tally,
physics, material or source cards is currently quite stiff to use with
models other than ISIS. As for materials, it would be better to rely on
model specific files for source definition, variance reduction etc...

Alberto

On 02/03/14 10:08, Stuart Ansell wrote:

Thanks for the comment. I think you are 100% correct. The lack of
separation starting to really annoy me. I would like all the model
specific
stuff out of the codebase into a kind of examples sub-directory. My
plan is
something like models / construction / Monte Carlo / Support.

Model: Clearly stuff only for one model , e.g. makeEss.cxx
Construction : Stuff that builds object but can be/are used in multiple
places, e.g. pipeLine.cxx / SupportPipe.cxx/ CylPreMod.cxx
Monte-Carlo : Transport, volumes, tallies, variances , weights etc Code
that is specific to most Mcnpx models but not to a particular model.
Support : Code like makeString, polynominal, Vec3D. Code that general
enough to be used in other projects. My simple test is that if I was given
the .cxx and .h files, I would not know that if came from a Monte-Carlo
modelling code.

Test is a mess and should just be split into test directories, maybe just
testModel, testConstruction etc.

I will start a new branch with my initial attempts. Feel free to
comment/change modify etc.

The ideas above are not set in stone, so if you think I have missed
something, there is a better way please let me know.

Stuart.

p.s. I am over on the 12th Feb at ESS for the pancake meeting [hence the
work on the pipe line].

p.p.s The adding of a new directory is another mess....

On 3 February 2014 09:23, Konstantin Batkov
[email protected]:

My major suggestion regarding the folder structure is to separate the
system files and the user source code, so that the later could live
somewhere outside the CombLayer folder. I think this separation is
logical
and common for many software projects and reduces amount of mess in the
folder structure.
Of course even now a user can separate his own code, but this
requires him
to write his own Makefile, which is not straightforward for some users.

Reply to this email directly or view it on
GitHubhttps://github.com//issues/5#issuecomment-33934861
.


Reply to this email directly or view it on GitHub
#5 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants