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

Add units support into command line #275

Open
alkichigin opened this issue Sep 11, 2020 · 2 comments
Open

Add units support into command line #275

alkichigin opened this issue Sep 11, 2020 · 2 comments
Assignees
Labels
comp-UI Related to user interface (command line, input files) maintainability Simplifies further code development (standardization, robustness) pri-Medium Worth assigning to a milestone usability Makes using code more convenient
Milestone

Comments

@alkichigin
Copy link

alkichigin commented Sep 11, 2020

Is your feature request related to a problem? Please describe.

ADDA is some sort of unit-less, and if -size is in um, then -lambda must be in um. It will be more convenient to introduce units into ADDA, but leave it optional

Describe the solution you'd like

Add second optional input variable for every command-line numerical parameter, so instead of "-size 1 -lambda .555" user could write "-size 1 um -lambda 555 nm"

Additional context

All output quantities must also be followed with the units they are expressed in

@myurkin myurkin added this to the 1.5 milestone Sep 13, 2020
@myurkin myurkin added comp-UI Related to user interface (command line, input files) feature Allows new functionality maintainability Simplifies further code development (standardization, robustness) pri-Medium Worth assigning to a milestone labels Sep 13, 2020
@myurkin
Copy link
Member

myurkin commented Sep 13, 2020

Adding units to the abovementioned command line options should be straightforward. However, it is not that trivial for some other options, like beams, which can accept several parameters of length dimension, like width and coordinates. Probably, we can add one optional unit parameter to the end, but it should be obvious for the user (and allow no ambiguity).

Thus, the first step in implementation should be a revision of the existing command line options to suggest how the units should be added.

Second step is the revision of existing output, suggesting how the units should be added everywhere. Also think whether this can lead to any problems with existing post-processing tools that parse ADDA output.

Third question is what should be the default behavior, when units are used in only some places of the command line, but not the other. One option is to assume um for each quantity independently, unless some other unit is given explicitly. Alternatively, we may allow behavior that if nm is mentioned somewhere, while no other length units are mentioned anywhere, then nm is assumed the default unit for everything. The confusion may arise for something like -size 1 um -lambda 500 nm -beam dipole 3 4 5.

This will also help with #253 . Both of these issues seem to have poor backwards compatibility, so that raises the question, how we should name the next version 1.5 or 2.0.

@alkichigin
Copy link
Author

"not that trivial for some other options, like beams, which can accept several parameters of length dimension" - it seems that it would be trivial and enough to introduce a new separate cmdline-parameter "-beam_center []"

@myurkin myurkin added usability Makes using code more convenient and removed feature Allows new functionality labels Apr 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp-UI Related to user interface (command line, input files) maintainability Simplifies further code development (standardization, robustness) pri-Medium Worth assigning to a milestone usability Makes using code more convenient
Projects
None yet
Development

No branches or pull requests

2 participants