Re: USRYIELD to look at photon emittance (mgdraw and BXDRAW)

From: Francesco Cerutti <Francesco.Cerutti_at_cern.ch>
Date: Mon, 12 Dec 2011 22:15:03 +0100

Dear Mina,

i. comment out all the WRITE statements in mgdraw but yours as well as all
the lines of the structures

        IF ( .NOT. LFCOPE ) THEN

but the one you added under BXDRAW. Correct back the latter putting

           OPEN ( UNIT = IODRAW, FILE = FILNAM, STATUS = 'NEW', FORM =
       & 'FORMATTED' )

This way the unit number and the file name can be controlled at input
level through the USERDUMP card (WHAT(2) and SDUM, respectively)

ii. NEVER call the geometry routines (GEOR2N) runtime (they take time!!).
Call instead, adopting an opposite logics, GEON2R and store once for
ever in your own integer variables (in principle to be saved by the SAVE
command) the region numbers corresponding to your region names:
           CALL GEON2R ( 'rdUCx0 ', MYREG0, IERR )
The above statement should go together with the OPEN command under the
LFCOPE condition, in order to be executed only once as the file is opened
and basta. Then your IF conditions will have to refer directly to MREG and
NEWREG, and by the way you will not need to define/use CHARACTER variables

[iii. Why do you define the FORMAT 100 and not use it in your WRITE
statement?]

Ciao

Francesco

**************************************************
Francesco Cerutti
CERN-EN/STI
CH-1211 Geneva 23
Switzerland
tel. ++41 22 7678962
fax ++41 22 7668854

On Mon, 12 Dec 2011, Mina Nozar wrote:

> Dear Alberto,
>
> Hello and thank you for your help. Defining MREGNAM and NEWREGNAM fixed the
> compilation issue. So I am closer.
>
> When I try a quick test run (50,000 primaries), I still see a huge hit in the
> processing time and the file that is generated is a binary file called MGDRAW
> (650 MB in size) and not the formatted file (*PhotEmit) as defined in mgdraw
> under BXDRAW,
>
> The processing time is increased from 2.5 min to 50 min.
>
>
> The USERDUMP card in the input file looks like:
> USERDUMP 100. 25.
>
> And the section in the MGDRAW under BXDRAW in regards to the output file
> looks like the following:
>
>
> ...
> IF(.NOT. LFCOPE)THEN
> LFCOPE=.TRUE.
> OPEN (UNIT=25, FILE="PhotEmit", STATUS='UNKNOWN')
> END IF
>
> WRITE(25,*) XSCO,YSCO,ZSCO,CXTRCK,CYTRCK,CZTRCK,ETRACK,WTRACK
> END IF
>
> 100 FORMAT(8(E10.4,1X))
> ...
>
>
>
>
> *****
> Compiling: /triumfcs/linux/fluka/fluka/2011.2.6/flutil/fff -b -N mgdraw.f
> mgdraw:
>
>
> *****
> Linking: /triumfcs/linux/fluka/fluka/2011.2.6/flutil/lfluka -o
> General_2ndDes2 -m fluka mgdraw.o
> $FLUPRO = /triumfcs/linux/fluka/fluka/2011.2.6
> now linking
> /triumfcs/linux/fluka/fluka/2011.2.6
> g77
> ar x /triumfcs/linux/fluka/fluka/2011.2.6/libflukahp.a fluka.o
> rm: cannot remove `General_2ndDes2.map': No such file or directory
> g77 -m32 -mcpu=pentiumpro -O3 -g -fexpensive-optimizations -funroll-loops
> -fstrength-reduce -Wall -fno-automatic -fno-silent -ffortran-bounds-check
> -I/triumfcs/linux/fluka/fluka/2011.2.6/flukapro -v -o General_2ndDes2
> -Xlinker -Map -Xlinker General_2ndDes2.map fluka.o mgdraw.o
> -L/triumfcs/linux/fluka/fluka/2011.2.6 -lflukahp
> Driving: g77 -m32 -mcpu=pentiumpro -O3 -g -fexpensive-optimizations
> -funroll-loops -fstrength-reduce -Wall -fno-automatic -fno-silent
> -ffortran-bounds-check -I/triumfcs/linux/fluka/fluka/2011.2.6/flukapro -v -o
> General_2ndDes2 -Xlinker -Map -Xlinker General_2ndDes2.map fluka.o mgdraw.o
> -L/triumfcs/linux/fluka/fluka/2011.2.6 -lflukahp -lfrtbegin -lg2c -lm
> -shared-libgcc
> Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-languages=c,c++,f77 --disable-libgcj
> --host=x86_64-redhat-linux
> Thread model: posix
> gcc version 3.4.6 20060404 (Red Hat 3.4.6-19.el6)
> /usr/libexec/gcc/x86_64-redhat-linux/3.4.6/collect2 --eh-frame-hdr -m
> elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o General_2ndDes2
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib/crt1.o
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib/crti.o
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/crtbegin.o
> -L/triumfcs/linux/fluka/fluka/2011.2.6
> -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/32
> -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6
> -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/32
> -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6
> -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib
> -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../.. -L/lib/../lib
> -L/usr/lib/../lib -Map General_2ndDes2.map fluka.o mgdraw.o -lflukahp
> -lfrtbegin -lg2c -lm -lgcc_s_32 -lgcc -lc -lgcc_s_32 -lgcc
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/crtend.o
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib/crtn.o
>
>
> *****
> Cmd: /usr/bin/nohup /triumfcs/linux/fluka/fluka/2011.2.6/flutil/rfluka -e
> General_2ndDes2 -M 1 test
> /usr/bin/nohup: ignoring input and appending output to `nohup.out'
>
>
>
>
>
>
>
> On 11-12-08 08:32 AM, Alberto Fasso' wrote:
>> Hi Mina,
>>
>> the compiler error messages are always cryptical.
>> Have you declared MREGNAM and NEWREGNAM as character variables?
>> You should have, at the beginning of mgdraw.f:
>>
>> CHARACTER*20 FILNAM, MREGNAM, NEWREGNAM
>> LOGICAL LFCOPE
>> etc....
>>
>> Alberto
>>
>> On Tue, 6 Dec 2011, Mina Nozar wrote:
>>
>>> Hello Francesco,
>>>
>>> Thank you for your reply. I have tried looking into mdgraw and BXDRAW but
>>> haven't had success yet.
>>> This is what I have tried so far:
>>>
>>> 1) Added the following USRDUMP card without modifying mgdraw.f
>>> USERDUMP 100. 25.
>>>
>>> The above created a binary file named test001_MGDRAW (I am assuming one
>>> would get created for each independent run) and
>>> creation of the file added (substantially) to the processing time. I
>>> don't know how to process this file.
>>>
>>>
>>> 2) Modified mgdraw.f and tried to compile and build the executable. Made
>>> the following changes under BXDRAW
>>>
>>>> ENTRY BXDRAW ( ICODE, MREG, NEWREG, XSCO, YSCO, ZSCO )
>>>> * Write in event file the position, direction, energy, and weight of
>>>> photons crossing Ta into target
>>>> IF(.NOT. LFCOPE)THEN
>>>> LFCOPE=.TRUE.
>>>> OPEN (UNIT=25, FILE="PhotEmit", STATUS='UNKNOWN')
>>>> END IF
>>>>
>>>> CALL GEOR2N ( MREG, MREGNAM, IERR1 )
>>>> CALL GEOR2N ( NEWREG, NEWREGNAM, IERR2 )
>>>> IF ((MREGNAM .EQ. "rTaEnUsW") .AND.
>>>> & ((NEWREGNAM.EQ."rdUCx0").OR.(NEWREGNAM.EQ."rdUCx1")
>>>> & .OR. (NEWREGNAM.EQ."rdUCx2").OR.(NEWREGNAM.EQ."rdUCx3")
>>>> & .OR. (NEWREGNAM.EQ."rdUCx4").OR.(NEWREGNAM.EQ."rdUCx5")
>>>> & .OR. (NEWREGNAM.EQ."rdUCx6"))
>>>> & .AND.
>>>> & (JTRACK .EQ. 7)) THEN
>>>> WRITE(25,*) XSCO,YSCO,ZSCO,CXTRCK,CYTRCK,CZTRCK,ETRACK,WTRACK
>>>> END IF
>>>>
>>>> 100 FORMAT(8(E10.4,1X))
>>>> RETURN
>>>
>>>
>>> Where rTaEnUsW is the upstream Tantalum window (region 1) and rdUCx0
>>> through rdUCx6 are seven target cylinders (seven
>>> regions) just downstream of rTaEnUsW. So the object is to look at all
>>> photons crossing from rTaEnUsW to any of the
>>> target cylinders rdUCx0-rdUCx6.
>>>
>>>
>>> When I tried to compile, I see:
>>> > mgdraw.f: In subroutine `mgdraw':
>>> > mgdraw.f:115:
>>> > IF ((MREGNAM .EQ. "rTaEnUsW") .AND.
>>> 1 2
>>> > Equality operator at (1) must operate on two scalar (not array)
>>> subexpressions, two function invocations returning
>>> > arithmetic or character scalars, or a combination of both -- but the
>>> subexpression at (2) is an array
>>> > mgdraw.f:116:
>>> > & ((NEWREGNAM.EQ."rdUCx0").OR.(NEWREGNAM.EQ."rdUCx1")
>>> 1 2
>>> > Equality operator at (1) must operate on two scalar (not array)
>>> subexpressions, two function invocations returning
>>> > arithmetic or character scalars, or a combination of both -- but the
>>> subexpression at (2) is an array
>>> > mgdraw.f:116:
>>> > & ((NEWREGNAM.EQ."rdUCx0").OR.(NEWREGNAM.EQ."rdUCx1")
>>> 1 2
>>> > Equality operator at (1) must operate on two scalar (not array)
>>> subexpressions, two function invocations returning
>>> > arithmetic or character scalars, or a combination of both -- but the
>>> subexpression at (2) is an array
>>>
>>> > ...
>>> > ...
>>> > ...
>>> > ...
>>>
>>>
>>> Can anyone help me with this please?
>>> Also, are there good examples as to how to understand and use user
>>> routines? I feel like I am like one of the
>>> blind-folded individuals trying to figure out what the elephant in the
>>> room is.
>>> I have looked through one of the Advanced course set of slides titled "Why
>>> user routines" but it is not much help.
>>>
>>> Any suggestion is much appreciated.
>>> Best wishes,
>>> Mina
>>>
>>>
>>>
>>> On 11-11-26 07:43 AM, Francesco Cerutti wrote:
>>>> Dear Mina,
>>>>
>>>>> Just to make sure, is the region selection for USRYIELD the same as for
>>>>> YSRBDX? ie. Two consecutive regions sharing a boundary with first region
>>>>> the upstream region and the second the downstream region?
>>>>
>>>> yes
>>>>
>>>>> To look at the photon emittance on the dUC3Gr target, I have used the
>>>>> upstream Tantalum window as Reg. 1 and dUC3Gr as Reg. 2. Is this the
>>>>> best choice?
>>>>
>>>> I would say yes, but talking about emittance one should consider,
>>>> together
>>>> with the angular distribution, also the spatial distribution. You could
>>>> get correlated info (photon position and direction, and energy) by a
>>>> customized scoring via the user routine mgdraw, entry BXDRAW
>>>>
>>>> Ciao
>>>>
>>>> Francesco
>
>
>
Received on Mon Dec 12 2011 - 22:42:04 CET

This archive was generated by hypermail 2.2.0 : Mon Dec 12 2011 - 22:42:04 CET