[Gate-users] phase space error
Sara Beilla
beilla.sara1 at gmail.com
Tue Apr 22 10:27:03 CEST 2014
Dear Stathis,
I 'm going to apply the modifications.
Thank you very much for the time and the help you gave me.
Best regards,
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: sara.beilla at inserm.fr
2014-04-19 21:01 GMT+02:00 Stathis Kamperis <ekamperi at gmail.com>:
> 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:
> GateSourcePhaseSpace.cc (l.252): Source phase space: particle not
> available in IAEA phase space format.
> 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
>
> On Sat, Apr 19, 2014 at 5:20 AM, Stathis Kamperis <ekamperi at gmail.com>
> wrote:
> > On Fri, Apr 18, 2014 at 11:04 PM, Stathis Kamperis <ekamperi at gmail.com>
> 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] http://permalink.gmane.org/gmane.comp.science.opengate.user/3701
> >> [2]
> http://www.opengatecollaboration.org/lxr/source/6.2.0/source/general/src/GateIAEARecord.cc#L68
> >> [3]
> http://www.opengatecollaboration.org/lxr/source/6.2.0/source/general/src/GateIAEARecord.cc#L159
> > Missing reference here:
> > [4]
> http://www.opengatecollaboration.org/lxr/source/6.2.0/source/general/include/GateIAEAConfig.h#L28
> >
> >>
> >>
> >> /*
> >> * 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 <beilla.sara1 at gmail.com>
> 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: sara.beilla at inserm.fr
>
-------------- section suivante --------------
Une pi�ce jointe HTML a �t� nettoy�e...
URL: <http://lists.opengatecollaboration.org/mailman/private/gate-users/attachments/20140422/69a7b4da/attachment.html>
More information about the Gate-users
mailing list