|
|
Dear Axel,
sorry for such a big delay in response. Now I going back to the problem of splash2txt.
I'm not exactly clear what modules are... ldd shows no problems, the binary itself starts normally. I'm not using ADIOS module at the moment, however it mentioned as an optional module.
Below you can find the output of the -v option:
danila@GPU: simOutput$ splash2txt -v
Usage splash2txt [options] <input-file>
:
-h [ --help ] print help message
-v [ --verbose ] verbose output, print status messages
-m [ --mode ] arg (=splash) File Mode [splash]
-l [ --list ] list the available datasets for an input file
--input-file arg parallel input file
-o [ --output-file ] arg output file (otherwise stdout)
-s [ --step ] arg (=0) requested simulation step
-d [ --data ] arg name of datasets to print
--slice arg (=xy) dimensions of slice for field data, e.g. xy
--offset arg (=0) offset of slice in dataset
--delimiter arg (= ) select a delimiter for data elements. default is
a single space character
--no-units no conversion of stored data elements with their
respective unit
So the command
danila@GPU: simOutput$ splash2txt --slice xy -s 50000 -d fields/FieldE/y --offset 128 --delimiter " " --input-file simData >& output
gives the same error after the long table of numbers...
danila@GPU: simOutput$ tail -n16 output
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
splash2txt: /home/danila/tools/picongpu/src/tools/splash2txt/tools_splash_parallel.cpp:200: void ToolsSplashParallel::printFields(std::vector<ExDataContainer>): Assertion `element != __null' failed.
[GPU-SERVER-97:07250] *** Process received signal ***
[GPU-SERVER-97:07250] Signal: Aborted (6)
[GPU-SERVER-97:07250] Signal code: (-6)
[GPU-SERVER-97:07250] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0) [0x7f0fa91e28d0]
[GPU-SERVER-97:07250] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x7f0fa7e94067]
[GPU-SERVER-97:07250] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7f0fa7e95448]
[GPU-SERVER-97:07250] [ 3] /lib/x86_64-linux-gnu/libc.so.6(+0x2e266) [0x7f0fa7e8d266]
[GPU-SERVER-97:07250] [ 4] /lib/x86_64-linux-gnu/libc.so.6(+0x2e312) [0x7f0fa7e8d312]
[GPU-SERVER-97:07250] [ 5] splash2txt(_ZN19ToolsSplashParallel11printFieldsESt6vectorI15ExDataContainerSaIS1_EE+0x2b2) [0x46e9fa]
[GPU-SERVER-97:07250] [ 6] splash2txt(_ZN19ToolsSplashParallel13convertToTextEv+0xa9a) [0x46f638]
[GPU-SERVER-97:07250] [ 7] splash2txt(main+0x278) [0x454597]
[GPU-SERVER-97:07250] [ 8] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f0fa7e80b45]
[GPU-SERVER-97:07250] [ 9] splash2txt() [0x452c2f]
[GPU-SERVER-97:07250] *** End of error message ***
Best regards,
Danila.
________________________________________
From: picongpu-users@hzdr.de [picongpu-users@hzdr.de] on behalf of Huebl, Axel [a.huebl@hzdr.de]
Sent: Thursday, June 16, 2016 2:55 PM
To: picongpu-users@hzdr.de
Subject: Re: [PIConGPU-Users] Field initializers
Dear Danila,
yes, in the case of experimentally measured data it is definitely the
right way to go through our HDF5 init for the density profiles instead
of trying to parametrize in case of complex measurements.
I think the quickest way in your case would be to write a small (python)
script that reads your data and does an interpolation to a given
discretization automatically by linear interpolation.
I scatched this a little in #1502 [1] but instead of "primitives" such
as cubes and spheres you would load your data and interpolate it to the
grid you want to use in the simulation (make the grid sizes and offset a
free parameter of this step in the script).
Performance: don't worry, we took care of that and read the profile
efficiently in a tree-like manner (first per GPU via MPI, then
distributed on the GPU via its threads).
Best,
Axel
On 16.06.2016 12:01, Khikhlukha Danila wrote:
> Hi Axel,
> thank you for your replay. Let me please comment on your email step by step.
> 1. C++ 11: thanks, I'll give it a shot. At the moment I just relaxed const qualifier and initialized test array in a constructor.
>
> 2. gasFreeFormula: Thanks for a hint. In fact I was tweaking the gasFreeFormula method to get a custom longitudinal gas profile. Let me please shortly describe a task I was trying to solve. Assume one has an experimentally measured (or simulated) gas profile specified on some grid. I want to use this profile for a pic simulation. The ideal solution IMHO would be to let picongpu to read the experimental profile, store it and re-sample it in a lazy way in gasFreeFormula:: SI:: GasProfile:: operator() by using the interpolation procedure. Since I was not sure how to read the file for the beginning I tried to store an experimental profile explicitly as a member of the GasProfile structure.
>
> Resampling an experimental profile externally and saving it to an HDF5 may be another option. However every time one plays with a picongpu grid the this procedure should be repeated...
>
> 3. HDF5 reader: Sorry, my question was not very clear. Unfortunately I didn't get a chance to take a closer look to h5 file format... I was curious if a lot of threads will try to read a custom profile from a file will it impact the performance?
>
> Thanks,
> Danila.
> ________________________________________
> From: picongpu-users@hzdr.de [picongpu-users@hzdr.de] on behalf of Huebl, Axel [a.huebl@hzdr.de]
> Sent: Thursday, June 16, 2016 11:05 AM
> To: picongpu-users@hzdr.de
> Subject: Re: [PIConGPU-Users] [PIConGPU-Users] Field initializers
>
> Hi Danila,
>
>> 1. If there is a way how to switch on the c++11 support for a
>> compilation?
>
> works only in `dev` right now, just configure (run cmake) with
> configure -c"-DCMAKE_CXX_STANDARD=11" [...]
>
> nevertheless, this is only a *warning* and still works.
> just move your "test" variable *inside* the operator() to get rid of the
> error "function-scope static variables cannot be initialized".
>
>> 2. If there is a less dirty way how to plug in a custom gas profile?
>> The custom HDF5 file is mentioned in the code, however I didn't find
>> the way how to use...
>
> 0.1.2:
> - componentsConfig.param: gasFreeFormula https://git.io/vo0zM
> - gasConfig.param: den(x,y,z) https://git.io/vo0z9
>
> so you can define anything you can describe as a function
> f(x, y, z) -> density
>
> is that not general enough?
>
> The alternative is "gasFromHdf5" where you pre-discretize a gas profile
> you want to use. I am thinking about providing a python-toolchain to
> build such files in the future from primitives [1], but for now one can
> simply create it with the same resolution as the planned simulation e.g.
> via matlab, h5py or what ever tool can write a HDF5 file with the
> density information (a very simple scalar matrix).
>
>> BTW, is it thread safe to read a gas profile from the file?
>
> Depends which kind of threads you refer to. PIConGPU's threads reading
> the file are of course coordinated reads and save, but you should not
> modify the gas profile file while PIConGPU is reading it.
>
>
> Best,
> Axel
>
> [1] https://github.com/ComputationalRadiationPhysics/picongpu/issues/1502
>
> On 14.06.2016 11:31, Khikhlukha Danila wrote:
>> Dear all,
>> I'm trying to tweak the gasProfile structure a bit. In fact I want to
>> specify a custom 1D gas distribution.
>> So currently I'm trying to initialize an array inside a gasProfile
>> declaration code:
>> struct
>> GasProfile
>>
>>
>> {
>>
>>
>> ....
>>
>>
>> const float_64 test[10] =
>> {0,1,2,3,4,5,6,7,8,9};
>>
>> DINLINE float_64 operator()( floatD_64 pos )
>> {....
>>
>> The code above gives an error during the compilation
>> .../simulation_defines/param/gasConfig.param(213): warning: field
>> initializers are a C++11 feature
>> .../simulation_defines/param/gasConfig.param(213): warning: field
>> initializers are a C++11 feature
>> .../simulation_defines/param/gasConfig.param(200) (col. 37): error:
>> Internal Compiler Error (codegen): "function-scope static variables
>> cannot be initialized!"
>>
>> So my questions are:
>> 1. If there is a way how to switch on the c++11 support for a
>> compilation? (w.r.t.
>> https://github.com/ComputationalRadiationPhysics/picongpu/issues/1147)
>>
>> 2. If there is a less dirty way how to plug in a custom gas profile? The
>> custom HDF5 file is mentioned in the code, however I didn't find the way
>> how to use... BTW, is it thread safe to read a gas profile from the file?
>>
>> Thank you in advance,
>> Danila.
>>
>>
>
> --
>
> Axel Huebl
> Phone +49 351 260 3582
> https://www.hzdr.de/crp
> Computational Radiation Physics
> Laser Particle Acceleration Division
> Helmholtz-Zentrum Dresden - Rossendorf e.V.
>
> Bautzner Landstrasse 400, 01328 Dresden
> POB 510119, D-01314 Dresden
> Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey
> Prof. Dr.Dr.h.c. P. Joehnk
> VR 1693 beim Amtsgericht Dresden
>
>
> #############################################################
> This message is sent to you because you are subscribed to
> the mailing list <picongpu-users@hzdr.de>.
> To unsubscribe, E-mail to: <picongpu-users-off@hzdr.de>
> To switch to the DIGEST mode, E-mail to <picongpu-users-digest@hzdr.de>
> To switch to the INDEX mode, E-mail to <picongpu-users-index@hzdr.de>
> Send administrative queries to <picongpu-users-request@hzdr.de>
>
--
Axel Huebl
Phone +49 351 260 3582
https://www.hzdr.de/crp
Computational Radiation Physics
Laser Particle Acceleration Division
Helmholtz-Zentrum Dresden - Rossendorf e.V.
Bautzner Landstrasse 400, 01328 Dresden
POB 510119, D-01314 Dresden
Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey
Prof. Dr.Dr.h.c. P. Joehnk
VR 1693 beim Amtsgericht Dresden
|
|