geometry position in predefined shapes

[GoogleCodeExporter]

Predefined shapes with different sizes can create a geometry file which
doesn't start at the zero position. 
Thus the whole target can be translated
in the space, and the "box size" comment in the geometry is not correct.
This is not a problem for adda itself but creates incompatibility
with the nearfield postprocessing.

Original issue reported on code.google.com by fabio.de...@gmail.com on 30 Jan 2011 at 5:31

[GoogleCodeExporter]

More details about particular runs that cause problem are given in discussion
http://groups.google.com/group/adda-discuss/browse_thread/thread/95c072f12169cad

Original comment by yurkin on 30 Jan 2011 at 6:03

• Added labels: Component-Logic, Usability

[GoogleCodeExporter]

Thanx.

I looked at the gendip code again and I can see why it doesn't work when the 
particle is not located at 0 in the geometry file.

Look at this code:
           rcx= ((imax-imix)*1.d0)/2.d0
           rcy= ((imay-imiy)*1.d0)/2.d0
           rcz= ((imaz-imiz)*1.d0)/2.d0
           icx=floor(rcx)
           icy=floor(rcy)
           icz=floor(rcz)

and

           bxx=(POS(i,1)-icx-0.5d0)*DX(1)                                                                                                
           byy=(POS(i,2)-icy-0.5d0)*DX(2)      
           bzz=(POS(i,3)-icz-0.5d0)*DX(3) 

ic(x,y,z) is the center of the particle relative to 0, i.e. it's its "radius" 
or "half length".
POS is the position of the particle in the geometry file, and as we found out 
not necessarily at 0.
So, the correct code that would handle a particle located NOT at 0 is:

           bxx=(POS(i,1)-imix-icx-0.5d0)*DX(1)                                                                                                
           byy=(POS(i,2)-imiy-icy-0.5d0)*DX(2)      
           bzz=(POS(i,3)-imiz-icz-0.5d0)*DX(3) 

Checked that with my gendip Matlab simulator and the results look OK.

I don't know whether there're other such gotchas. We'll know after we fix and 
pass gendip.

David

Original comment by qwer1...@gmail.com on 30 Jan 2011 at 6:57

[GoogleCodeExporter]

Here is the modified gendip.exe: 
http://code.google.com/p/a-dda/downloads/detail?name=gendip.exe 
I did exactly the modification that David mentioned, and the file worked well 
(see attached output) with test case, that David sent previously
http://groups.google.com/group/adda-discuss/msg/ea97e3963f47b741
However, I did no other tests.

Please test.

Original comment by yurkin on 30 Jan 2011 at 12:47

Attachments:

• out.txt

[GoogleCodeExporter]

Original comment by yurkin on 30 Jan 2011 at 12:48

• Added labels: OpSys-All

[GoogleCodeExporter]

r1008 solves the problem with shape files, discussed in this issue. There were 
indeed some inaccuracies in the determination of computational box dimensions, 
so that extra void dipoles were created. This had no effect on the simulation 
results, but caused some waste of computational resources and strange shape 
files.  I am attaching here a new Win32 executable of ADDA for testing. David, 
please test whether it works OK.

However, there are still some weird ways to make ADDA produce "broken" shape 
files (where sizes in the headers for y and z are larger than in reality, and 
dipole count for y and z start not from 0). For example, this can be done by 
using -grid option with 3 arguments. Then user specifies y and z dimensions of 
computational box by hand, possibly larger than needed. ADDA then just places 
the particle in the center of the computational box.

But I consider such behavior normal, because the header shows the size of the 
computational box and the lines below define the particle. Copying the 
computational box as is can be important for debugging. In other words, shape 
files do not only provide interfaces with other programs, but they also provide 
a precise image of ADDA computational domain. Of course, the manual should 
explicitly mention possible caveats. But do you think such ideology is 
self-consistent or is it very inconvenient and should be changed? 

So my another proposal is not to rely in any other programs on the fact that 
dipole count starts from 0 in ADDA shape files. Fabio, a question for you. Will 
near_field package work fine with such broken shape files if the above 3-line 
fix is implemented? If yes, then I propose to submit this fix to ADDA 
repository (either Fabio or I can do it) for additional reliability.

Original comment by yurkin on 30 Jan 2011 at 6:52

• Added labels: Milestone-1.1

Attachments:

• adda.exe

[GoogleCodeExporter]

I checked the new version and it looks OK.
Also, results of the whole chain (adda+nearfield) looked similar with the two 
combinations (old adda+fixed gendip, new adda+fixed gendip). 
However, I did notice that the numbers weren't identical, so it seems that 
there're some additional effects beyond gendip.
Geometry where particle's location along axes doesn't have to begin with 0 is a 
more general one.  

Original comment by qwer1...@gmail.com on 31 Jan 2011 at 6:41

[GoogleCodeExporter]

David, do you mean that the final results for computed near-field differs? If 
yes, can you please provide more details. And can it be due translation of the 
particle geometry of the new shape files relative to the old one (now they do 
start with 0)? In other words, it could be that using the same parameters for 
input of near_field routines leads to a shifted position of plane of interest 
relative to the particle.

Original comment by yurkin on 31 Jan 2011 at 6:50

[GoogleCodeExporter]

I ran two full sets (adda+nearfield), one with new adda and new gendip and 
another with old adda and new gendip.

I'm attaching two archives with all the files generated and plots of the 
resulting field (it's rar format, since zip is over 10MB limit)

As you can see there's similarity between the two, but they're far from being 
identical.

I also added the output from nearfield as nearfield.log. Notice the difference 
in Error_beam.

David

Original comment by qwer1...@gmail.com on 31 Jan 2011 at 9:39

Attachments:

• run-new_new.rar
• run-old_new.rar

[GoogleCodeExporter]

Maxim,

Could you please provide a moi-build of adda with the fix, please?

Thx,
David

Original comment by qwer1...@gmail.com on 2 Feb 2011 at 12:38

[GoogleCodeExporter]

Here is a MPI-build for Win32 from the current source. Please mind, however, 
that we are now in the middle of implementation of GPU-acceleration for ADDA. 
Although it should influence neither the standard sequential nor MPI versions 
of the code, all kind of weird things can potentially happen. So please test 
the simulation results for consistency (and against the sequential version I 
posted above) before making production runs.

Original comment by yurkin on 2 Feb 2011 at 6:31

Attachments:

• adda_mpi.exe

[GoogleCodeExporter]

I just noticed that the following combination:
-size 0.12 -shape cylinder 6.6667 -orient 270 270 0 -m 0.05 3.1309 -lambda 0.5

generates the following:
lambda: 0.5
shape: cylinder; diameter(d):0.12, height h/d=6.6667
box dimensions: 16x16x106
refractive index: 0.05+3.1309i
Dipoles/lambda: 67.284

so, the length of the cylinder is: 106*0.5/67.284*1000=787.7nm versus the 
required:
.12*6.6667*1000=800nm

I understand that adda requires an even number of dipoles, but if it used 108 
dipoles instead of 106 it'd have 108*0.5/67.284*1000=802.6nm which is much 
closer to the required 800nm.

This is with version 1.1a6

Original comment by qwer1...@gmail.com on 10 Feb 2011 at 4:13

[GoogleCodeExporter]

Concerning the last comment, the main reason for the strangeness of the output 
is the volume correction. In this case the dipoles are slightly deflated to 
have the volume exactly equal to the prescribed one. So 106 is the proper 
choice for the original size of dipoles, but looks wrong after deflation. Try 
adding the command line "-no_vol_cor" to see the difference.

Original comment by yurkin on 12 Feb 2011 at 4:51

[GoogleCodeExporter]

I consider this issue finally fixed by r1017.

Original comment by yurkin on 12 Feb 2011 at 5:24

• Changed state: Fixed

[GoogleCodeExporter]

Here are new Win32 executables of near_field package for testing.

Original comment by yurkin on 12 Feb 2011 at 5:28

Attachments:

• near_field_win32_r1017.zip

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have found other legitimate ways to create weird shape files. For instance,
adda -grid 6 -ellipsoid 1 1.5 
will produce box 6x6x10 but only 8 dipoles along the z-axis will be occupied. 
In such cases the minimal grid can only be accurately calculated after the 
shape is fully generated. I have created a separate enhancement request for 
that - issue 129.

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