Hi Mikhail,
You're previous message concerned me. It wouldn't be unreasonable for
this to have been an issue; this was something I had to overcome before
when testing against the default subroutine (without calling the SOURCE
card).
After consulting the manual and looking into those variables within
their source file COMMON BEAMCM ($FLUPRO/flukapro/(BEAMCM), I have found
these definitions for the parameters:
L29: * Xbeam = beam spot centre (geom frame) x-coordinate (cm) *
L30: * Ybeam = beam spot centre (geom frame) y-coordinate (cm) *
L31: * Zbeam = beam spot centre (geom frame) z-coordinate (cm) *
L32: * Ubeam = beam direction cosine wrt the (beam frame) x-axis *
L33: * Vbeam = beam direction cosine wrt the (beam frame) y-axis *
L34: * Wbeam = beam direction cosine wrt the (beam frame) z-axis *
The position is with respect to the geometry frame, which is +100cm
above the centre along the y-axis.
However the direction cosines are with repect to the beam frame set by
BEAMAXIS. The BEAMAXIS card should set the beam axis frame such that
+z_beam = -y_geom, therefore you would expect UBEAM, VBEAM, and WBEAM to
be 0, 0, and 1 respectively.
Damn it, I thought we were onto something there. I think I will surround
the cube with detector planes. Hopefully they will inform me which
direction these particles are going.
Thanks,
On Tue, Apr 28, 2015 at 07:10:23PM +0300, "Mikhail Polkovnikov <Михаил Полковников> " wrote:
> Dear Matthew,
>
> Part of the input file:
>
>
> DEFAULTS NEW-DEFA
> BEAM -5.0 0.0 0.0 0.0 0.0 0.0PROTON
> BEAMPOS 0.0 100.0 0.0 0.0 0.0
> * ..+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
> BEAMAXES 0.0 0.0 -1.0 0.0 -1.0 0.0
> SOURCE
> * ..+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
>
> Here is a part of source file:
>
> C FIRST CALL INITIALISATIONS
> IF (LFIRST) THEN
> C THE FOLLOWING 3 CARDS ARE MANDITORY
> TKESUM = ZERZER
> LFIRST = .FALSE.
> LUSSRC = .TRUE.
> WRITE(LUNOUT, *) 'ARMSTRONG FLUX SOURCE, ',
> + 'BY MATTHEW PARNELL'
>
> WRITE (LUNOUT, *) 'COSINES: ', UBEAM, VBEAM, WBEAM
> WRITE (LUNOUT, *) 'BEAMPOS: ', XBEAM, YBEAM, ZBEAM
>
> WRITE(LUNOUT, *) ' FLUKA PARTICLE NUM ', IJBEAM
> ENDIF
>
>
> And here is an output:
>
> ARMSTRONG FLUX SOURCE, BY MATTHEW PARNELL
> COSINES: 0.0000000000000000 0.0000000000000000 1.0000000000000000
> BEAMPOS: 0.0000000000000000 100.00000000000000 0.0000000000000000
> FLUKA PARTICLE NUM 1
>
>
> So the beam position is correct, but the direction cosines of source
> particle is different.
> If the direction along is a negative Y-axis, the values should be 0, -1, 0.
>
> Best regards.
>
> On 28.04.2015 18:31, Matthew Parnell wrote:
> > Hi Mikhail,
> >
> > Thank you for your input, I will attempt with your modifications as my
> > next test, however I doubt there shouldn't be a difference.
> >
> > If I point you to the bottom of p.367 and the top of p.368, and the 2nd
> > Importand note on that same page, of the FLUKA Manual ($FLUPRO/FM.pdf),
> > UBEAM, VBEAM, WBEAM, XBEAM, YBEAM, and ZBEAM correspond the the values
> > for the direction cosines and positions given by the BEAMPOS card. If
> > the card is not given, then the defaults are used; 0, 0, 1, 0, 0, 0
> > respectively.
> >
> > I have a BEAMPOS card, therefore these values should be set correctly.
> >
> > However if manually setting the direction and position of the beam
> > within the source seems to work, then this suggests an issue getting
> > the correct values from COMMON BEAMCM.
> >
> > Best regards,
> >
> > On Tue, Apr 28, 2015 at 04:39:40PM +0300, "Mikhail Polkovnikov <Михаил Полковников> " wrote:
> > > Dear Matthew,
> > >
> > > I hope experts correct me if i'm wrong.
> > >
> > > 1. All the sources files you have attached were compiled without any
> > > warnings, at least in the arch_laptop directory.
> > > I'm using: glibc-2.21, gcc-4.8.4, ld-2.24
> > >
> > > 2. When you link your SOURCE routine and enable SOURCE card in your input
> > > file, you */have to /*define beam direction and beam position in a routine
> > > file by yourself. As i understood the proton beam travels along Y-axes in
> > > negative direction in your input, but in SOURCE routine it travels along
> > > Z-axes in positive direction because it uses default values of UBEAM, VBEAM
> > > and WBEAM.
> > >
> > > As a result your primary particles travel in vacuum without any interactions
> > > to the outer blackhole region! That is why your simulation works for a 5
> > > seconds.
> > >
> > > According to you BEAMPOS and BEAMAXES cards:
> > > * Cosines (tx,ty,tz)
> > > TXFLK (NPFLKA) = +ZERZER
> > > TYFLK (NPFLKA) = -ONEONE
> > > TZFLK (NPFLKA) = +ZERZER
> > > * Particle coordinates
> > > XFLK (NPFLKA) = XBEAM
> > > YFLK (NPFLKA) = 100.D0
> > > ZFLK (NPFLKA) = ZBEAM
> > >
> > > 3. Here is my version of your source with proton and neutron parameters as
> > > constants.
> > >
> > > Best regards.
> > >
> > > On 27.04.2015 16:23, Matthew Parnell wrote:
> > > > NOTE: I apploguise if you have received this message mutliple times.
> > > > Attachments can be found here:http://hep.lancs.ac.uk/~parnmatt/FLUKA/
> > > >
> > > > Hi Vittorio,
> > > >
> > > > Sorry for the late reply, something else needed my attention.
> > > >
> > > > I have compiled, linked and ran using the example, my predecessors, and
> > > > my own SOURCE subroutines, and ran the builtin and default. For each of
> > > > them I redirected the stdout and stderr to a file.
> > > >
> > > > I have included those files, and all other generated files (*.err,
> > > > *.log, *.out, etc.) as well as the SOURCE subroutines and input files.
> > > >
> > > > I have done this for both my laptop running Arch and my workstation
> > > > running SL6.6, and have attached them in compressed archives.
> > > >
> > > > I have also attached the commands I used to do this, for clarity and
> > > > to ensure I am not missing fundamental understanding in the linking
> > > > process. (Which I might be).
> > > >
> > > > The SOURCE subroutine is just the same as the example, but with the
> > > > weighting calculated differently. My subroutine looks radically
> > > > different, however it is just written in a different style.
> > > >
> > > > If there is anything else that I can send, please let me know. It is
> > > > imperative I get this simple thing working.
> > > >
> > > > Best regards,
> > > >
> > > > On Wed, Apr 22, 2015 at 08:09:53PM +0200, Vittorio Boccone wrote:
> > > > > Dear Matthew,
> > > > > sure Arch is a rolling distro. What I meant was "versions" plural of the
> > > > > base-devel pack group. Anyway I see I've got almost the same devel packages
> > > > > group as you.
> > > > >
> > > > > gcc/gfortran 4.9.1 is not what I would call stable for the centos.
> > > > >
> > > > > To get a new g++/gfortran suite on the CentOS I would try the devtoolset
> > > > > 2.1 which provides all the gcc.gfortran 4.8.2 in a nutshell.
> > > > > [seehttp://linux.web.cern.ch/linux/devtoolset/#dts21 and other RH/CentOS
> > > > > posts on the list]
> > > > >
> > > > > I have some simulation which uses a custom source routing which are both
> > > > > running on SL6.6 or Arch.
> > > > > It's a bit complicate to reproduce your error w/o the input or source or to
> > > > > give you some hint w/o the log or err files.
> > > > > Could you post some more detail?
> > > > > Best,
> > > > > V.
> > > > >
> > > > > On Wed, Apr 22, 2015 at 6:27 PM, Matthew Parnell<m.parnell_at_lancaster.ac.uk>
> > > > > wrote:
> > > > >
> > > > > > Hi Vittorio,
> > > > > >
> > > > > > Arch is a rolling release, therefore there is no 'version' of it.
> > > > > > However I have using gfortran 4.9.2 20150304, ld 2.25.0, and fluka
> > > > > > 2011.2c gfor64bitAA.
> > > > > >
> > > > > > I have attempted to compile and link the example SOURCE subrouteine,
> > > > > > $FLUPRO/usermvax/source.f
> > > > > >
> > > > > > I am not getting errors or warnings in the compliation or linking,
> > > > > > however the program stops running after 5s. Similar to my own SOURCE and
> > > > > > the SOURCE by my predecessor [which he apparently got to work].
> > > > > >
> > > > > > What is interesting, is leaving the SOURCE command within the input file
> > > > > > and running fluka runs for a similar time of 5s, whereas leaving out the
> > > > > > SOURCE card runs correctly for around 12mins.
> > > > > >
> > > > > > To ensure it's not my laptop, I tried with my workstation running
> > > > > > Scientific Linux 6.6, with the gfortran updated to 4.9.1 [FLUKA needed
> > > > > > gfortran > = 4.6, SL6 has 4.4.7].
> > > > > >
> > > > > > My workstation seems to have the same issues. My SOURCE, my predecessors
> > > > > > SOURCE, and the example SOURCE subroutines.
> > > > > >
> > > > > > However I both my laptop (Arch) and my workstation (SL6.6) work without
> > > > > > the SOURCE card with the default rfluka, and run for around 12mins, with
> > > > > > output.
> > > > > >
> > > > > > Now I guess I am running it wrong and/or it's a linking issue, not my
> > > > > > source, and not my input file.
> > > > > >
> > > > > > Any ideas?
> > > > > >
> > > > > > --
> > > > > > Matthew Parnell
> > > > > > m.parnell_at_lancaster.ac.uk
--
Matthew Parnell
m.parnell_at_lancaster.ac.uk
__________________________________________________________________________
You can manage unsubscription from this mailing list at https://www.fluka.org/fluka.php?id=acc_info
Received on Tue Apr 28 2015 - 21:38:01 CEST