Closed GoogleCodeExporter closed 8 years ago
is this feature difficult to implement? we would like to test vectorial
Gaussian beams in Adda. Reading the incident field from a file would be
sufficient for this task.
Original comment by vita...@gmail.com
on 1 Sep 2011 at 1:48
There are several complexity levels for this issue.
The simplest approach is to read the file in the same format as is currently
used for reading shape (using six real numbers for complex vector instead of
one integer, which is now used for domain number). Then the grid in the file
should perfectly match the one inside ADDA, which is a complete responsibility
of the user. And the user should perform a transformation of integer
coordinates (in numbers of dipoles) in the shape file into real coordinates
(e.g. in nm) to compute the incident field.
Of course, this is not a critical limitation. One can for example run a test
run with
"-prognosis -save_geom -store_int_field" which will produce two files with
one-to-one correspondence (e.g. by line numbers) between these two types of
coordinates.
A harder issue is to implement some kind of consistency check or even to accept
incident field on arbitrary grid with interpolation to a dipole grid if
necessary.
Finally, since you are interested in this issue, I will try to implement the
simplest approach by next release. The time frame is, hopefully, about one
month.
Original comment by yurkin
on 1 Sep 2011 at 5:26
Hi Maxim, I appreciate your prompt reaction. If you think that I could be (with
very limited C++ programming skills) of any help, please let me know. With
thanks, vita.
Original comment by vita...@gmail.com
on 2 Sep 2011 at 9:59
Hi Vita,
It seems to be really easy to implement. So I just need to sit down and do it.
But I will definitely use your help for testing.
Original comment by yurkin
on 2 Sep 2011 at 5:49
r1083 adds new command line option '-beam read <filenameY> [<filenameX>]',
which should be sufficient for playing with incident field. The beam is
specified in the particle reference frame exactly in the same format as from
'-store_beam'. Therefore '-prop ...' and '-orient ...' has only minor effect:
a) by defining the reference frame for calculation of amplitude and Mueller
matrices. However, this should not effect values obtained by integration over
the whole scattering angles, e.g. Csca.
b) by slightly affecting of polarizability value (for LDR, CLDR, and possibly
SO formulations)
Since ADDA expects exact correspondence (including order of lines) of the input
beam file to the internal dipole distribution, the recommended workflow is like
this
1) adda <options defining scattering problem> -store_beam [-sym no]
'-sym no' can be used to enforce production of two incident beams even for
symmetric shapes.
2) copy the files IncBeam-Y (and IncBeam-X) from the output directory to the
working folder (usually one level up)
3) replace the values of plane wave in the obtained files by the values
computed by yourself
4) adda <options defining scattering problem> -beam read IncBeam-Y [IncBeam-X]
[-sym enf]
'-sym enf' can be used to indicate that both shape and the beam are
rotationally symmetric. Then second beam file is not needed.
Current limitations are:
1) issue 30 - also workarounds are possible (see also '-sym enf' above).
Moreover, one can just run ADDA with single beam file. ADDA will correctly
calculate all values stored in *-Y files, but then exit with an error.
2) issue 134 (although if tilted plane wave is supplied, Cext would be
correct), and issue 135.
Original comment by yurkin
on 23 Nov 2011 at 4:35
Half of the issue (input of incident beam) is implemented (see above), at least
in beta stage. So I shift the milestone for the remaining parts to the next
release.
Original comment by yurkin
on 21 Mar 2012 at 4:56
This issue was closed by revision r1223.
Original comment by yurkin
on 4 May 2013 at 5:16
In addition to previous comment - r1223 also changed handling of errors. Now if
only one field is given (when two are required), the error will appear
immediately (before processing Y polarization). So use of "-sym enf" in
workaround described above is now mandatory.
Original comment by yurkin
on 4 May 2013 at 5:19
Original issue reported on code.google.com by
yurkin
on 26 Nov 2008 at 6:27