[Trilinos-Users] Nonlinear maps & VectorToMatrixMarketFile

[Klosiewicz Przemyslaw]

Alright, makes sense.
Thanks a lot.

Przemyslaw


On 11 May 2011, at 01:28, Heroux, Michael A wrote:

> Przemyslaw,
> 
> I finally had a chance to look at this issue.  The function is working as
> expected.  It is not intended that the output vector be reordered based on
> its map.  In fact, a common use case when the map is not linear is to write
> the map out and the vector.  That way the map can be read in first, then the
> vector can be read in using that map to recreate the vector as it was prior
> to writing it out.
> 
> The way to get the behavior you want, you should use the import
> functionality just as you did in the example you sent to me.
> 
> Sorry for the delay.
> 
> Mike
> 
> 
> On 5/8/11 11:34 AM, "Klosiewicz Przemyslaw" <Przemyslaw.Klosiewicz at ua.ac.be>
> wrote:
> 
>> Any ideas?
>> 
>> Greetings,
>> Przemyslaw
>> 
>> 
>> On 29 Apr 2011, at 19:18, Klosiewicz Przemyslaw wrote:
>> 
>>> Hi all,
>>> 
>>> Up till now I've been using EpetraExt::VectorToMatrixMarketFile(...) and
>>> similar to quickly dump distributed vectors to files. However, as soon as
>>> "custom-defined" maps for these vectors are used the family of the above IO
>>> functions generates results suggesting the requirement of a default linear
>>> map.
>>> As an example, consider an 'interleaving' map:
>>> 
>>> int myGlobalElements[2];
>>> if (comm.MyPID() == 0) {
>>> myGlobalElements[0] = 0;
>>> myGlobalElements[1] = 2;
>>> } else {
>>> myGlobalElements[0] = 1;
>>> myGlobalElements[1] = 3;
>>> }
>>> Epetra_Map map(4, 2, myGlobalElements, 0, comm);
>>> 
>>> and a vector:
>>> 
>>> Epetra_Vector v(map);
>>> for (int idx = 0; idx < map.NumMyElements(); idx++) {
>>> v[idx] = comm.MyPID();
>>> }
>>> 
>>> to create the vector [0, 1, 0, 1] when executed on 2 nodes. A quick cout << v
>>> indicates that all is fine.
>>> Writing the file with VectorToMatrixMarketFile("v.mtx", v) though, gives:
>>> 
>>> %%MatrixMarket matrix array real general
>>> 4 1
>>> 0.0000000000000000e+00
>>> 0.0000000000000000e+00
>>> 1.0000000000000000e+00
>>> 1.0000000000000000e+00
>>> 
>>> The right behavior can of course be obtained by using a suitable
>>> Epetra_Import but I was expecting the IO functions not to depend on linear
>>> ordering.
>>> Is this a bug, a feature or am I missing something crucial?
>>> 
>>> Thanks,
>>> Przemyslaw
>>> 
>>> 
>>> --
>>> Przemyslaw Klosiewicz
>>> PhD Student @ CoMP Research Group
>>> Department of Mathematics and Computer Science, University of Antwerp
>>> Middelheimlaan 1, 2020 Antwerp, Belgium
>>> 
>>> Office (G2.07):  T (+32) 3 265 32 80, F (+32) 3 265 37 77, E
>>> Przemyslaw.Klosiewicz at ua.ac.be
>>> Home: T (+32) 497 24 18 82, E przemek.klosiewicz at gmail.com, Skype
>>> przemek_klosiewicz
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Trilinos-Users mailing list
>>> Trilinos-Users at software.sandia.gov
>>> http://software.sandia.gov/mailman/listinfo/trilinos-users
>>> 
>> 
>> --
>> Przemyslaw Klosiewicz
>> PhD Student @ CoMP Research Group
>> Department of Mathematics and Computer Science, University of Antwerp
>> Middelheimlaan 1, 2020 Antwerp, Belgium
>> 
>> Office (G2.07):  T (+32) 3 265 32 80, F (+32) 3 265 37 77, E
>> Przemyslaw.Klosiewicz at ua.ac.be
>> Home: T (+32) 497 24 18 82, E przemek.klosiewicz at gmail.com, Skype
>> przemek_klosiewicz
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Trilinos-Users mailing list
>> Trilinos-Users at software.sandia.gov
>> http://software.sandia.gov/mailman/listinfo/trilinos-users
> 
> 
> _______________________________________________
> Trilinos-Users mailing list
> Trilinos-Users at software.sandia.gov
> http://software.sandia.gov/mailman/listinfo/trilinos-users
> 

--
Przemyslaw Klosiewicz
PhD Student @ CoMP Research Group
Department of Mathematics and Computer Science, University of Antwerp
Middelheimlaan 1, 2020 Antwerp, Belgium

Office (G2.07):  T (+32) 3 265 32 80, F (+32) 3 265 37 77, E Przemyslaw.Klosiewicz at ua.ac.be
Home: T (+32) 497 24 18 82, E przemek.klosiewicz at gmail.com, Skype przemek_klosiewicz