Hi Ole,
The reason for this lies basically in the need to optimize memory consumption and also speed for every mode the code is run in.
In Gadget-1 I still tried to follow the philosophy of having only one executable for all types of simulations (which has obvious advantages). But this eventually turned out to cause too much overhead in certain cases, for example by having variables in the central structures describing a particle that are not needed for certain types of runs. Wasting this space is not really an option for us. We therefore have to interfere at the source code level, even if this is ugly.
It would certainly be possible to get rid off a number of the compile time options and move them to the parameterfile, but some of these options will remain, and hence the fundamental issue cannot be eliminated easily.
Best regards,
Volker
On 10 Nov 2015, at 12:32, debian-devel_at_liska.ath.cx wrote:
>
> Hi Volker,
>
> is there a reason that these simulation options are not set in the parameter file? Apart from some very basic ones (like single/double precision, or the inclusion of HDF5) it looks if one could replace the #ifdefs with runtime options.
>
> Best regards
>
> Ole
>
> On 06.11.2015 20:27, Volker Springel wrote:
>> Hi Ole,
>>
>> Thanks for your interest in doing this. However, I should point out
>> one thing: Gadget2 is configured for specific types of simulation
>> through a bunch of compile-time options, i.e. one typically creates a
>> new executable for each simulation one wants to do. I’m afraid, this
>> severely limits the utility of any precompiled binary...
>>
>> On Nov 5, 2015, at 11:22 AM, Ole Streicher
>> <debian-devel_at_liska.ath.cx> wrote:
>>
>>>
>>> Hi,
>>>
>>> I am currently preparing a Debian package for gadget2 [1], and I
>>> have a few qestions:
>>>
>>> There are basically two homepages:
>>>
>>> http://wwwmpa.mpa-garching.mpg.de/galform/gadget/
>>> http://wwwmpa.mpa-garching.mpg.de/gadget/
>>>
>>> which seem quite similar. However, the first one offers
>>> "gadget-2.0.7.tar.gz" (and an n-genic.tar.gz IC code), but the
>>> second one just a "gadget2.tar.gz" (and no iC-code). Which one is
>>> the recent one?
>>>
>>
>> Both are identical. (The second file is a symbolic link to the
>> version 2.0.7)
>>
>>
>>> Second question is about HDF-5. I could compile the code with the
>>> Debian version of hdf5 (1.8.8) when I apply the -DH5_USE_16_API
>>> flag. Is this OK or will it run into problems?
>>
>> This would be OK.
>>
>>>
>>> Finally, the example ICs that come with the code seem to be a
>>> problem for the packaging: Debian requires that everything is built
>>> from the sources, but the source of these files seems to be not
>>> distributed with the package, right? Is there a way to re-generate
>>> them somehow? Otherwise, I would need to leave them out, which
>>> would make it much harder for a beginner to start.
>>
>> Regenerating these files would require to include various initial
>> conditions codes as well. This is not readily possible.
>>
>> Regards, Volker
>>
>>
>>>
>>> The packaging is done in a git repository [2]. If you have any
>>> hints or comments regarding the packaging, please let me know.
>>>
>>> Best regards
>>>
>>> Ole
>>>
>>> [1] http://bugs.debian.org/804074 [2]
>>> https://anonscm.debian.org/cgit/debian-astro/packages/gadget2.git
>
>
>
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> minimalist_at_MPA-Garching.MPG.de with a subject of: unsubscribe gadget-list
> A web-archive of this mailing list is available here:
> http://www.mpa-garching.mpg.de/gadget/gadget-list
Received on 2015-11-11 10:28:21