Dear Roy, On Thu, 4 Sep 2008, Roy Stogner wrote:
>> I see, you are also calling serial vectors "global vectors" now. > > Just one subset of serial vectors: those for which every coefficient > is valid. Okay, so we have parallel and serial vectors, where serial vectors can be divided into global and non-global vectors. >> Does the vector have to decide on its constuction whether it is a parellel, >> serial or sparse vector? > > Currently the constructor makes the decision between serial and > parallel vector. I looked into it and found out (which certainly is well-known to you, but new to me) that the type of a vector can be changed during its lifetime by calling init(), although this of course clears the data. Actually, operator=() uses this trick. > In the near term, I'd like to replace non-global > serial vectors with sparse vectors to get rid of the O(N) allocations > of zeros. In the long term, I'd like to also replace parallel vectors > with sparse vectors to get rid of the solution/current_local_solution > redundancies. Very good idea, since this redundancy is always driving me crazy, because I never know which vector is the correct one to use. But since your last mail, I am starting to understand this a bit better. So, writing should be performed to "solution" only, and after finishing writing, System::update() should be called to reflect things on "current_local_solution", right? I am trying to implement a higher order Runge-Kutta time stepping scheme that requires a large number of additional vectors (about 8). I guess the best thing is to make these vectors parallel, because the only thing I have to do with them is to copy them between each other and the "solution" vector and/or to multiply them with scalars. Also, I see that currently neither the grid nor the data will scale as expected with respect to memory (as long as ParallelMesh is not released), because "current_local_solution" is a serial copy of "solution" (not to mention "old_local_solution" for transient systems). Well, that's of course the reason for you to say that you would like to change that in the near. >> By the way, if I add additional vectors to a system using add_vector(), I >> assume they are stored parallel as well, right? > > Let me see... I think System postpones the initialization, so that you > can init() such vectors manually (like TransientSsytem::init_data > does) to make them serial or parallel as you prefer. No, they are initialized in System::init_data() and it's parallel then. (It's different in TransientSystem, since that does not use System::add_vector().) Sorry for first asking you and then looking it up myself. I'm just learning, and I think I did a lot things wrong in my application. Summarizing the remainder of the email, I think I just have to wait for ParallelMesh to be released, since this will solve at least some of my problems. Best Regards, Tim -- Dr. Tim Kroeger Phone +49-421-218-7710 [EMAIL PROTECTED], [EMAIL PROTECTED] Fax +49-421-218-4236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.-O. Peitgen ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
