[parsec-users] extending input set for fluidanimate

Kirak Hong hokira at gatech.edu
Sun Mar 28 23:23:29 EDT 2010


Hi Jin,

Thanks a lot. Meanwhile I took a look into the source code and it seems the
actual number of particles processed are not just depending on the number of
particles in the input file, but also depending on the grid settings and
which cell do those particle belong to.

However, I still want to use some different input files that contain
different number of particles. Do you know what program can generate the
input file of fluidanimate? I saw Intel RMS from somewhere but I couldn't
find any specific program.

Thanks!
Kirak

2010/3/25 Jim Dempsey <jim at quickthreadprogramming.com>

>  Kirak,
>
> The input file in_500K.fluid contains 501,642 particles not 500 particles.
> The smallest non-test file in_35K has 36,504 particles.
>
>
> If you read InitSim or SaveFile you can see the sequence in which the header andthen
>  particles are written (this is a binary file).
>
> When looking at the visualization of in_35K the initial state of the
> particles appears to be different than that of the in_500K files (and not
> simply a difference in particle count). in_35K produces a 4-pointed crown
> early on, whereas in_500K produces a bursting bubble early on. In both cases
> the initial state have the particles suspended above the equilibrium point
> such that they drop into the domain (box so to speak) then splash around
> (different effect for each file). I haven't run the other simulation files
> to produce the initial screenshots.
>
> I suggest you experiment with in_35K while you are examining the code. In
> Debug build with enable visualization (on 4 core) you get fairly decent
> frame rates and can see anomalies in the data points should you introduce
> code changes that contain errors. The in_500K runs relatively slow on a
> Q6600 with the visualization enabled. GLUT wasn't designed with displaying
> 501,642 points in mind.
>
> This is the 35K image
>
>
> The particles dropped, 4 waves propagate from walls towards center, the
> "crown" points are the intersection of two waves, with well in middle.
>
> The in_500K image is different, see image below
>
> The waves from the walls propagate to middle and form a high pressure
> bubble which bursts.
>
> I think this has more to do with initial state of particles than it does
> with number of particles. Also the box sizes are different.
> I sent Chris an update that aids in the colorization of the display. This
> was run on Windows XP.
>
> Jim
>
>
>
>  ------------------------------
> *From:* parsec-users-bounces at lists.cs.princeton.edu [mailto:
> parsec-users-bounces at lists.cs.princeton.edu] *On Behalf Of *Kirak Hong
> *Sent:* Thursday, March 25, 2010 7:33 PM
>
> *To:* PARSEC Users
> *Subject:* Re: [parsec-users] extending input set for fluidanimate
>
> Sorry, let me make my question clear.
>
> If I have an input file containing 500 particles, is there any way to run
> fluidanimate with particle numbers 1, 2, 3, ..., 500?
>
> Thanks,
> Kirak
>
> On Thu, Mar 25, 2010 at 8:24 PM, Kirak Hong <hokira at gatech.edu> wrote:
>
>> Hi,
>>
>> I wanted to have more input data to see different behaviors of
>> fluidanimate regarding different inputs.
>> So the possible solutions based on my understanding are :
>>
>> 1. clone particles (hack the input)
>> 2. randomly generate particles
>> 3. take inputs from outputs
>>
>> Is this true?
>>
>> If it is true, my problem now is that I don't know the input file format
>> for fluidanimate. Could you tell me what's the input format and what program
>> takes uses the ".fluid" files? I saw that it is from Intel RMS application,
>> but I have no idea about that.
>>
>> Thanks!
>> Kirak
>>
>> 2010/3/25 Jim Dempsey <jim at quickthreadprogramming.com>
>>
>>>   Chris, Kirak,
>>>
>>> For benchmarking I think the 500K is more than adequate for 1P or 2P
>>> systems. 500K x 104 = ~50MB data. On 4P or 8P systems 500K particles could
>>> fit in cache (at 12/24MB per processor). A larger data set would be
>>> appropriate for these systems. I could see a need to generate 1M, 2M, 4M, 8M
>>> and 16M particles. So I think a feature should be incorporated into
>>> fluidanimate (or application added) whereby the domain dimensions, cell size
>>> and and number of particles be specified, and then which will generate a
>>> test data set.
>>>
>>> An alternate way to accomplish this auto-magically, would be for the
>>> initial particle domain dimensions, cell size and particle count, be
>>> duplicated/multiplied as an input option. The additional particle domains
>>> would then be abutted together. Example,
>>>
>>> The 55 cell x 76 cell x 55 cell domain can be (by option) specified to be
>>> doubled, thus producing
>>> 110 cell by 76 cell x 55 cell particle domain, or quadrupled, thus
>>> producing
>>> 110 cell by 76 cell x 110 cell particle domain.
>>>
>>> The 76 cell Y is along the direction of gravity and would likely not need
>>> to be extended.
>>> The trailing options could be x, y, and z multipliers
>>>
>>> serial 1 0 in_500k.fluid in_2M.fluid 2 1 2
>>>
>>> Run Serial.exe, 1 thread, 0 frames, input file in_500k.fluid, output file
>>> in_2M.fluid, dimension x doubled, dimension y unchanged, dimension z
>>> doubled.
>>>
>>> Or the user could simply run with the multipliers and smaller input file
>>>
>>> This has as an additional benefit of being able to ship PARSEC with
>>> smaller data files.
>>>
>>> Jim
>>>
>>>
>>>  ------------------------------
>>> *From:* parsec-users-bounces at lists.cs.princeton.edu [mailto:
>>> parsec-users-bounces at lists.cs.princeton.edu] *On Behalf Of *Christian
>>> Bienia
>>> *Sent:* Thursday, March 25, 2010 3:40 PM
>>>
>>> *To:* 'PARSEC Users'
>>> *Subject:* Re: [parsec-users] extending input set for fluidanimate
>>>
>>>    Kirak,
>>>
>>>
>>>
>>> Jim’s suggestion should give you a good input with not too much work.
>>> Another approach would be to write a synthetic input generator that will
>>> generate random inputs with any amount of particles. You need to vary the
>>> initial position and velocity of the particles. You also must make sure that
>>> particles start within the bounding box and do not initially move too fast,
>>> otherwise the simulation will become numerically unstable. The upper bound
>>> on the velocity is given by the grid size and the time step size.
>>>
>>>
>>>
>>> If you use significantly more particles you might want to consider to
>>> increase the volume of the bounding box. The particles should fit in
>>> comfortably.
>>>
>>>
>>>
>>> Why exactly do you want bigger inputs?
>>>
>>>
>>>
>>> - Chris
>>>
>>>
>>>
>>>
>>>
>>> *From:* parsec-users-bounces at lists.cs.princeton.edu [mailto:
>>> parsec-users-bounces at lists.cs.princeton.edu] *On Behalf Of *Jim Dempsey
>>> *Sent:* Thursday, March 25, 2010 3:48 PM
>>> *To:* 'PARSEC Users'
>>> *Subject:* Re: [parsec-users] extending input set for fluidanimate
>>>
>>>
>>>
>>> Kirak,
>>>
>>>
>>>
>>> More than 500K particles?
>>>
>>>
>>>
>>> If so, as a quick and dirty "hack", edit the SaveFile such that it
>>> doubles the particle count and writes each particle twice. Run the
>>> in_500K.fluid in, and write out in_1M.fluid. Repeat this to double the
>>> particle counts. Probably it would be best to add an additional argument to
>>> specify the multiplier (and so you do not have to remember to remove
>>> the"hack"). You might want to add a randomizer to the point duplicator such
>>> that no two particles come in at exactly the same position. You might want
>>> to keep the replicated particles within a reasonably close position. Should
>>> the resultant file cause an explosion in the particles (blast out of the
>>> bottom of the domain well) you can use the display mode and let the
>>> simulation run until it has quieted down somewhat (but not all the way).
>>> Then reset the simulation without display to run to that frame number. The
>>> output file is now a reasonable approximation of what you might want.
>>>
>>>
>>>
>>> Jim Dempsey.
>>>
>>>
>>>  ------------------------------
>>>
>>> *From:* parsec-users-bounces at lists.cs.princeton.edu [mailto:
>>> parsec-users-bounces at lists.cs.princeton.edu] *On Behalf Of *Kirak Hong
>>> *Sent:* Thursday, March 25, 2010 2:35 PM
>>> *To:* parsec-users at lists.cs.princeton.edu
>>> *Subject:* [parsec-users] extending input set for fluidanimate
>>>
>>> Hi,
>>>
>>> I am trying to make more input data set for fluidanimate in parsec 2.1.
>>> I tried to find out input format and how to generate extra input data,
>>> but didn't find anything yet.
>>> Has anybody tried this before? Any help would be highly appreciated!
>>>
>>> Thanks!
>>> Kirak
>>>
>>> _______________________________________________
>>> parsec-users mailing list
>>>
>>> parsec-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
>>>
>>>
>>
>
> _______________________________________________
> parsec-users mailing list
> parsec-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/parsec-users/attachments/20100328/85aeb72d/attachment.htm>


More information about the parsec-users mailing list