<div dir="ltr"><div><div>Dear Stathis, I 'm going to apply the modifications. Thank you very much for the time and the help you gave me. </div>Best regards, </div>Sara <div><div> </div></div></div><div class="gmail_extra"> <div><div dir="ltr"><div> ________________________________________________ Beilla Sara </div><div>Doctorante en Charge d'Enseignement </div><div>INSERM UMR825 </div><div>Imagerie Cérébrale & Handicaps Neurologiques </div><div>CHU PURPAN - Pavillon Baudot </div><div>Bureau 326 - 3ème étage </div><div>Place du Dr Baylac 31024 TOULOUSE - Cedex 3 </div><div>E-mail: <a href="mailto:sara.beilla@inserm.fr" target="_blank">sara.beilla@inserm.fr</a> </div></div></div> <div class="gmail_quote">2014-04-19 21:01 GMT+02:00 Stathis Kamperis <<a href="mailto:ekamperi@gmail.com" target="_blank">ekamperi@gmail.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> To summarize, the steps one needs to go through in order to use IAEA phase space files are, in my opinion, the following: 1. Take a backup of the phase space file. 2. Edit the program I quoted in my previous email, so that: The sum of 'pad' array size plus 1 equals the record length as found in the header file. 3. Compile the program, e.g. gcc chkphsp.c -o chkphsp 4. Run the program on the phase space file, e.g. ./chkphsp <your phase space file here> 5. If there are errors, it means that there exist unknown particles inside the phase space file that GATE can't handle. The program will try to fix them by replacing them with photons, for DEBUGGING purposes only. Rerun the program a 2nd time. This time there should be no output. 6. If there are no errors (either because there weren't any at the first place or because they were 'fixed' by the utility), you can proceed. Run your simulation with the phase space file as your beam source. Most likely the simulation will terminate prematurely with an error: <div class=""> GateSourcePhaseSpace.cc (l.252): Source phase space: particle not available in IAEA phase space format. </div>7. From now own, 2 are the main causes that may be to blame: 7a. Your phase space file uses a fixed 'Z' coordinate. 7b. Your phase space file contains extra longs or extra floats. Regarding 7a. I have already provided a hard-coded fix in my previous emails. Regarding 7b: If your CPU architecture is 32bits wide, then you need to set 'iextralong' (or 'iextrafloat') in the general/src/GateIAEARecord.cc file to the number of extra longs (or extra floats) your header file says there are. If your CPU architecture is 64bits wide, on top of adjusting 'iextralong', you need to change 'typedef long IAEA_I32;' into 'typedef int32_t IAEA_I32;' and also include stdint.h in source/general/include/GateIAEAConfig.h file. 8. #define DEBUG in source/general/src/GateIAEARecord.cc file, 9. Rebuild GATE. 10. Run your simulation and see the printed messages regarding the read particles. Make sure that the values are meaningful (particle type, energy, x,y,z, u,v,w, statistical weight). E.g., the direction cosines need to be bounded on [-1,1] and so on. I hope that my last emails will provide you with enough information to get you started. I'm off. Best regards, Stathis <div class="HOEnZb"><div class="h5"> On Sat, Apr 19, 2014 at 5:20 AM, Stathis Kamperis <<a href="mailto:ekamperi@gmail.com">ekamperi@gmail.com</a>> wrote: > On Fri, Apr 18, 2014 at 11:04 PM, Stathis Kamperis <<a href="mailto:ekamperi@gmail.com">ekamperi@gmail.com</a>> wrote: >> Greetings, >> >> the usage of IAEA phase space files is problematic in many levels. >> >> Most of the times, in my experience, the actual record length of the >> space file is not interpreted correctly. E.g., record length is 53 >> bytes but GATE assumes some other length (for reasons I am going to >> list later). >> >> This is a typical case of a framing error (similar to genetics where a >> mutation occurs that inserts or deletes a *single* nucleotide from a >> DNA sequence and all the triplets past that mutation are translated >> incorrectly). The end result is that soon (i.e., after a few particles >> are read) some particle ends up with a particle number other than >> those that are supported (1-5) and GATE fails with: >> >> "GateSourcePhaseSpace.cc (l.252): Source phase space: particle not >> available in IAEA phase space format." >> >> So, an error like the above is indicative that GATE and phase space >> files don't agree on the actual record length. >> >> In Sara's case, the header file looks like this: >> >> $RECORD_CONTENTS: >> 1 // X is stored ? >> 1 // Y is stored ? >> 1 // Z is stored ? >> 1 // U is stored ? >> 1 // V is stored ? >> 1 // W is stored ? >> 1 // Weight is stored ? >> 0 // Extra floats stored ? >> 6 // Extra longs stored ? >> 1 // Incremental history number stored in the extralong array [ 0] >> 0 // Generic integer variable stored in the extralong array [ 1] >> 0 // Generic integer variable stored in the extralong array [ 2] >> 0 // Generic integer variable stored in the extralong array [ 3] >> 0 // Generic integer variable stored in the extralong array [ 4] >> 3 // ILB PENELOPE variable stored in the extralong array [ 5] >> >> So: >> 1 byte for particle type + >> 4 bytes for energy + >> 6*4 bytes for (x,y,z,u,v,w) + >> 4 bytes for weight factor + >> 6*4bytes for the extra longs >> sum = 57 bytes >> >> But the header file says: >> >> $RECORD_LENGTH: >> 53 >> >> If you recall my previous analysis that can be found here[1] GATE >> doesn't check for 'W' no matter the value of it in the header file. So >> 'W' is as if it doesn't exist. I don't understand though why the >> header says '1' and doesn't count it later on in the record length. I >> would expect that the header file, at least, would be self-consistent, >> i.e., the sum of record contents would always equal record length. >> >> So: >> 1 byte for particle type + >> 4 bytes for energy + >> 5*4 bytes for (x,y,z,u,v) + >> 4 bytes for weight factor + >> 6*4bytes for the extra longs >> sum = 53 bytes >> >> But the header file says: >> >> $RECORD_LENGTH: >> 53 >> >> So, we are good! But why GATE can't read a record ? >> >> Well, it seems that GATE doesn't read the value of longs or floats >> from the header file, but instead uses some defaults[2]. So, if one >> uses a phase space with extra longs or floats either s/he needs to >> stop using them or inject the correct value of 'iextralong' or >> 'iextrafloat' in GATE and rebuild. Sara is using 6 extra longs so >> 'iextralong' needs to be 6. Right ? Well, not exactly :) >> >> If you take a look here[3], you see that the long array which holds >> the extra longs is declared as IAEA_I32. Considering the name one >> would expect that this is a variable 32 bits long (=4bytes), no matter >> your CPU architecture (32 or 64bits). But, if you look at the >> definition of it here[4], you realize that it is typedef'd to 'long'. >> But sizeof(long) might be 4 bytes on 32 bit CPUs or 8 bytes like mine >> or whatever. So, for me, 'iextralong' needs to be '3' and not '6', >> since 3*8 = 6*4. > Actually, the safest way to go is to fix the definition of IAEA_I32, > like for instance: > > typedef int32_t IAEA_I32; > > (and also include stdint.h) > >> >> If I do this Sara, the phase space files that you sent me are >> interpreted fine and the simulation continues uninterrupted. >> >> Best regards, >> Stathis >> >> _____ >> [1] <a href="http://permalink.gmane.org/gmane.comp.science.opengate.user/3701" target="_blank">http://permalink.gmane.org/gmane.comp.science.opengate.user/3701</a> >> [2] <a href="http://www.opengatecollaboration.org/lxr/source/6.2.0/source/general/src/GateIAEARecord.cc#L68" target="_blank">http://www.opengatecollaboration.org/lxr/source/6.2.0/source/general/src/GateIAEARecord.cc#L68</a> >> [3] <a href="http://www.opengatecollaboration.org/lxr/source/6.2.0/source/general/src/GateIAEARecord.cc#L159" target="_blank">http://www.opengatecollaboration.org/lxr/source/6.2.0/source/general/src/GateIAEARecord.cc#L159</a> > Missing reference here: > [4] <a href="http://www.opengatecollaboration.org/lxr/source/6.2.0/source/general/include/GateIAEAConfig.h#L28" target="_blank">http://www.opengatecollaboration.org/lxr/source/6.2.0/source/general/include/GateIAEAConfig.h#L28</a> > >> >> >> /* >> * A debugging ONLY program that checks a phase space file for unknown particles >> * and replaces them with photons. If you still get an unknown particle error >> * after you run this on you phase space file (take a backup first), then you >> * have a frameshift error. >> */ >> >> #include <assert.h> >> #include <stdio.h> >> >> #define ABS(x) ((x)<0 ? -(x) : (x)) >> >> struct rec { >> char particle; >> char pad[52]; /* 1 + 52 = 53 bytes which is the record >> length as found in the header file */ >> } __attribute__((packed)); >> >> int >> main(int argc, char *argv[]) >> { >> FILE *fp; >> struct rec r; >> int cnt, rv; >> >> fp = fopen(argv[1], "r+"); >> assert(fp); >> >> cnt = 0; >> do { >> ++cnt; >> rv = fread(&r, sizeof(struct rec), 1, fp); >> assert(rv > 0 || (rv == 0 && feof(fp))); >> /* Particle number maybe negative, that's OK. */ >> char part = ABS(r.particle); >> if (part != 1 && part != 2 && part != 3 && part !=4 && >> part != 5) { >> printf("Wrong particle=%d at record=%d byte=%ld", >> r.particle, cnt, ftell(fp)); >> /* Override unknown particle with a photon */ >> r.particle = 1; >> assert(fseek(fp, -sizeof(struct rec), SEEK_CUR) != -1); >> assert(fwrite(&r, sizeof(struct rec), 1, fp) == 1); >> printf(" [Fixed]\n"); >> } >> } while(!feof(fp) && !ferror(fp)); >> >> assert(fclose(fp) != -1); >> >> return 0; >> } >> >> On Mon, Apr 14, 2014 at 11:43 AM, Sara Beilla <<a href="mailto:beilla.sara1@gmail.com">beilla.sara1@gmail.com</a>> wrote: >>> Dear Gaters, >>> >>> I used a phase space created by PRIMO ( Software allowing to create a phase >>> space) but when i lauched my simulation i have an error message: >>> >>> /home/beilla/Software/gate_v6.2/source/physics/src/GateSourcePhaseSpace.cc >>> (l.252): Source phase space: particle not available in IAEA phase space >>> format. >>> >>> i didn't find solution to this problem in messages already posted. >>> >>> I have already check in GateSourcePhaseSpace.cc and my phase space, my >>> particles are indentified (gamma, e-, e+) >>> >>> Thank you in advance. >>> >>> Best regards, >>> >>> Beilla Sara >>> >>> ________________________________________________ >>> >>> Beilla Sara >>> >>> Doctorante en Charge d'Enseignement >>> >>> INSERM UMR825 >>> Imagerie Cérébrale & Handicaps Neurologiques >>> CHU PURPAN - Pavillon Baudot >>> Bureau 326 - 3ème étage >>> Place du Dr Baylac 31024 >>> TOULOUSE - Cedex 3 >>> E-mail: <a href="mailto:sara.beilla@inserm.fr">sara.beilla@inserm.fr</a> </div></div></blockquote></div> </div>