[overture] Re: Parallel Moving Grid Memory Usage
- From: Kyle Hord <kmhord01@xxxxxxxxx>
- To: overture@xxxxxxxxxxxxx
- Date: Fri, 15 Jun 2012 14:05:15 -0400
Dr. Henshaw,
Thanks for looking into the problem. The memory used usually accumulates
over time. The values I gave were after the cgins had run to a time of 2.5
and completed the simulation. (Values taken from the finish output) At the
beginning of the simulations the memory used was always reasonable, but the
slow accumulation due to the possible leak at away at the server's memory.
Trying a newer version sounds great, always worth a shot. I believer we are
using mpich2 version 1.4 on two of the servers, not sure about the third.
Thanks
Kyle
On Thu, Jun 14, 2012 at 11:26 PM, Bill Henshaw <henshaw@xxxxxxxx> wrote:
> Hi Kyle,
>
> Thanks for the files (although they were a little funny with \par at the
> end of every line and various symbols changed, e.g. \} instead of }).
>
> Note that it is inefficient to convert Cartesian grids into NURBS (only
> certain mappings such as DPM's need to be converted to NURBS for parallel)
> so I used the Cartesian versions instead. Note that currently a NURBS
> surface
> or volume is NOT distributed but replicated across all processors so one
> should avoid
> making a NURBS with too many knots -- one can still define a fine GRID on
> a NURBS by
> choosing the number of lines to be greater than the number of knots that
> define the NURBS. The grid for a Nurbs mapping is distributed. For the case
> below it did not make much of a difference since the grids are so coarse.
>
>
> Below are the memory usage I get for running the 2nd order version
> of the cgins in parallel. I report the memory usage from cgins along
> with the output from "top" (the column `RES' -- resident set size, is
> an estimate of the memory used). This was with graphics on, which increases
> the memory usage somewhat (10M ?). You will see that the memory
> per core decreases as the number of processors increases, from 103M to 70M
> to 60M. I do not
> see the behaviour that you report. These results used
> mpich-1.2.7p1 and my latest version of cgins on red-hat linux.
> Now I do see that memory usage does increase slowly with time. The
> results below were after about 100 steps. After 1000 steps the memory
> usage is about 50% greater. Thus there is a memory leak somewhere that
> I will have to track down. To get around this you can restart the
> computation if the memory usage gets too large.
>
> Thus either I have fixed something in my version compared to your version
> (I don't recall any major change that would affect this) or there is a
> problem
> with your compilers, version of mpi, or your operating system. I can
> provide you
> with a more recent version of cg/Overture if you want to test it.
>
> Regards,
> Bill.
>
> ++++++++++++++++++++++++++++++**++++++++++++++++++++++++++++++**
> ++++++++++++++++
>
> 1 processor:
>
> ==== memory per-proc: [min=103.891,ave=103.891,max=**103.891](Mb),
> max-recorded=0 (Mb), total=103.891 (Mb)
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 27557 henshaw 25 0 343m 103m 22m R 99.7 0.9 0:27.51 cgins
>
> ++++++++++++++++++++++++++++++**++++++++++++++++++++++++++++++**
> ++++++++++++++++
> 2 processors:
>
> ==== memory per-proc: [min=60.4375,ave=70.7949,max=**81.1523](Mb),
> max-recorded=0 (Mb), total=141.59 (Mb)
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 27648 henshaw 16 0 325m 79m 22m R 88.1 0.7 0:18.77 cgins
> 27665 henshaw 16 0 298m 56m 19m S 66.3 0.5 0:13.79 cgins
>
>
> ++++++++++++++++++++++++++++++**++++++++++++++++++++++++++++++**
> +++++++++++++++++++
> 4 processors
>
> ==== memory per-proc: [min=56.8906,ave=60.1982,max=**66.3086](Mb),
> max-recorded=0 (Mb), total=240.793 (Mb)
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 27817 henshaw 17 0 292m 52m 19m R 93.9 0.4 0:11.84 cgins
> 27800 henshaw 16 0 309m 63m 22m R 84.7 0.5 0:12.03 cgins
> 27834 henshaw 16 0 292m 50m 19m R 78.4 0.4 0:10.44 cgins
> 27851 henshaw 16 0 292m 54m 19m R 76.1 0.5 0:10.81 cgins
>
> ++++++++++++++++++++++++++++++**++++++++++++++++++++++++++++++**
> +++++++++++++++++++
>
>
>
>
>
>
>
>
>
> On 06/14/2012 08:27 AM, Kyle Hord wrote:
>
>> Dr. Henshaw,
>>
>> Here are the two files for the simulation. The cg script should be setup
>> for the original moving grids matrix motion.
>>
>> Kyle
>>
>
>
>
Other related posts:
