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

Remove limitations of grid size dimensions to be even #95

Closed
GoogleCodeExporter opened this issue Aug 12, 2015 · 2 comments
Closed

Remove limitations of grid size dimensions to be even #95

GoogleCodeExporter opened this issue Aug 12, 2015 · 2 comments
Assignees
Labels
comp-UI Related to user interface (command line, input files) feature Allows new functionality performance Simulation speed, memory consumption pri-High Of higher priority, but no guarantees usability Makes using code more convenient
Milestone

Comments

@GoogleCodeExporter
Copy link

Currently, even dimensions of grid is enforced at input and assumed inside
the code. That is not a big problem in most applications (if needed the
grid size is automatically incremented by one). Odd number of dipoles per
dimension of the scatterer can be used (e.g. read from shape file), but
such shapes can't be produced automatically inside ADDA (except, 'line' shape).

Giovanni Pellegrini reported an interesting idea to compute light
scattering by dipole monolayers. Unfortunately, such shapes can't be
produced by a '-shape box' option (the width is set to two dipoles by the
ADDA). Although a workaround exist (e.g. by saving dipoles to file and
manually deleting the second layer), the limitation of even grid sizes
should be removed.

This seems to be quite easy, but care should be exercised not to break the
code. In other ways, we should locate all the places where assumption of
evenness is used.

However, making a separate shape 'plane' also makes sense, since it would
automatically ensure that exactly one dipole is used for width (in contrast
to 'box' shape).




Original issue reported on code.google.com by yurkin on 20 May 2010 at 5:05

@GoogleCodeExporter GoogleCodeExporter added OpSys-All pri-High Of higher priority, but no guarantees comp-UI Related to user interface (command line, input files) usability Makes using code more convenient performance Simulation speed, memory consumption labels Aug 12, 2015
@GoogleCodeExporter
Copy link
Author

Original comment by yurkin on 16 Feb 2011 at 3:14

  • Added labels: Milestone-1.2, Performance

@GoogleCodeExporter
Copy link
Author

Original comment by yurkin on 28 Apr 2013 at 3:51

  • Added labels: Priority-High
  • Removed labels: Milestone-1.2, Priority-Medium

@myurkin myurkin added feature Allows new functionality and removed Type-Enhancement labels Aug 13, 2015
@myurkin myurkin self-assigned this Nov 12, 2015
@myurkin myurkin added this to the 1.5 milestone Jul 10, 2018
@myurkin myurkin assigned dsmunev and unassigned myurkin Jul 10, 2018
@myurkin myurkin modified the milestones: 1.5, 1.4 Jul 12, 2018
dsmunev added a commit to dsmunev/adda that referenced this issue Jul 12, 2018
Compatibility restriction 'rect_dip' and '-beam [lminus, barton5, davis3, dipole, read]' removed
@dsmunev dsmunev mentioned this issue Jul 12, 2018
6 tasks
@myurkin myurkin closed this as completed Nov 3, 2018
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) feature Allows new functionality performance Simulation speed, memory consumption pri-High Of higher priority, but no guarantees usability Makes using code more convenient
Projects
None yet
Development

No branches or pull requests

3 participants