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

Renaming Ionization Framework #963

Closed
1 task done
n01r opened this issue Jul 27, 2015 · 5 comments
Closed
1 task done

Renaming Ionization Framework #963

n01r opened this issue Jul 27, 2015 · 5 comments
Assignees
Labels
refactoring code change to improve performance or to unify a concept but does not change public API

Comments

@n01r
Copy link
Member

n01r commented Jul 27, 2015

I would like to rename all parts in the ionization framework to enhance transparency and to avoid misunderstandings.
Therefore I would propose the following changes:

ionization.hpp --> ionization.kernel
After all the refactoring all that is left of the contents is the kernel.
ionization/byField/ionizers.[def|hpp] --> ionization/byField/fieldIonizationModels.[def|hpp]
because these files just collect the .def and .hpp files of the models and thus are a list of the models
AlgorithmADK[None/BSI/...].hpp --> ADK[BSI/none/...]Calc.hpp
All files belonging to a certain model should have names starting with the model name, right?
otherwise: CalcADK? CompADK? ADKComp[utation]?
Introduce a new file fieldIonizationCalc.hpp
containing all the includes for the calculation of the models, like e.g. ADKCalc.hpp

Do you think ionizerConfig.[param|unitless] can keep its name? Right now it just does forward declaration / collects includes but I am positive that we might soon get model-specific quantities that we will have to make unitless. (e.g. Keldysh parameter)

  • To do after changes: update the Wiki

Please feel free to suggest more suitable names if you can think of any.

@n01r n01r mentioned this issue Jul 27, 2015
1 task
@ax3l ax3l added the refactoring code change to improve performance or to unify a concept but does not change public API label Jul 27, 2015
@ax3l ax3l added this to the Open Beta milestone Jul 27, 2015
@n01r
Copy link
Member Author

n01r commented Jul 28, 2015

Does anyone have suggestions?

@ax3l
Copy link
Member

ax3l commented Aug 10, 2015

I already updated the regex' in your description to be valid. so generally, yes :D

starting the file name with the model groups the model-related files nicely together, that's good.
Calculation and Computation is a bit too general, maybe we can find something more specific. If you want to denote the actual core if the implementation, @psychocoderHPC used the ...Impl.abc prefix in the last commits quite regular.

@n01r
Copy link
Member Author

n01r commented Aug 10, 2015

Yeah, well I wanted to know if everyone is happy with the names I'm suggesting or if people can think of better ones! 😉

@ax3l
Copy link
Member

ax3l commented Nov 11, 2016

@n01r done?

@n01r
Copy link
Member Author

n01r commented Nov 11, 2016

So far, yes. The next change will come with #1357.

@n01r n01r closed this as completed Nov 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactoring code change to improve performance or to unify a concept but does not change public API
Projects
None yet
Development

No branches or pull requests

2 participants