On Sun, 7 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
> Well if they truly have the same size it should be really easy
Yeah, no kidding - if there's no complicated metadata and no
likelihood of format changes then forget what I said about HDF5,
reading and writing a bunch of identical vectors to
On 10/07/2012 10:38 AM, Kirk, Benjamin (JSC-EG311) wrote:
> Just a couple other questions:
>
> (1) th coefficients are distributed in the parallel case, right? So they do
> need to be gathered for serialization?
Yeah, we just get the coefficients by doing a solve and then copying
from system.s
Just a couple other questions:
(1) th coefficients are distributed in the parallel case, right? So they do
need to be gathered for serialization? If this is the case and they are all
distributed then it'll be easy to reduce the number of mpi calls from
nproc*nvec to just nproc, already a huge
That'd be awesome, thanks!
On 10/07/2012 09:35 AM, Kirk, Benjamin (JSC-EG311) wrote:
> Well if they truly have the same size it should be really easy - Ill have
> some time on a flight Tuesday if you want me to take a shot at it.
>
> -Ben
>
>
>
> On Oct 7, 2012, at 8:11 AM, "David Knezevic"
>
Well if they truly have the same size it should be really easy - Ill have some
time on a flight Tuesday if you want me to take a shot at it.
-Ben
On Oct 7, 2012, at 8:11 AM, "David Knezevic" wrote:
>
> On 10/07/2012 09:05 AM, Kirk, Benjamin (JSC-EG311) wrote:
>> The file format os secondar
On 10/07/2012 09:05 AM, Kirk, Benjamin (JSC-EG311) wrote:
> The file format os secondary at this point - Xdr is already there and gets
> you platform independent binary files, (as does netcdf for that matter). HDF5
> can do the same, and there are other good reasons to support linking to it,
>
The file format os secondary at this point - Xdr is already there and gets you
platform independent binary files, (as does netcdf for that matter). HDF5 can
do the same, and there are other good reasons to support linking to it, but I
don't want to get the cart before the horse...
Probably the
This seems like the right way to go. Starting to add HDF5 support
isn't a bad idea anyway...
Derek
Sent from my iPhone
On Oct 6, 2012, at 7:59 PM, Roy Stogner wrote:
>
> On Sat, 6 Oct 2012, David Knezevic wrote:
>
>> I agree, I think we do need a specialized I/O implementation that
>> concate
On 10/06/2012 09:59 PM, Roy Stogner wrote:
>
> On Sat, 6 Oct 2012, David Knezevic wrote:
>
>> I agree, I think we do need a specialized I/O implementation that
>> concatenates vectors. The key parts of the RB code related to this are
>> at line 873 and 940 of rb_evaluation.C. We currently write (o
On Sat, 6 Oct 2012, David Knezevic wrote:
> I agree, I think we do need a specialized I/O implementation that
> concatenates vectors. The key parts of the RB code related to this are
> at line 873 and 940 of rb_evaluation.C. We currently write (or read) a
> bunch of vectors one after the other, b
Hi all,
I wanted to pick up on this thread again. I gather that a change was
made to the block size in read_serialized_data that led to a significant
speedup for the use case that Jens was looking at.
But this is still a bottleneck for a lot of the reduced basis code, so
I'd like to improve it
11 matches
Mail list logo
