From: Yujie <rec...@gm...> - 2008-11-21 00:47:02
|
Dear Libmesh developers: I notice that if i need to add vectors in LinearImplicitSystem using System::add_vector() it must be done before System::init(). However, I can't confirm the vector number at the beginning. How to dynamically add vectors? In addition, In the same LinearImplicitSystem, the vectors added by add_vector() have similar characteristics with the variable added by add_variable(), such as parallel distribution, same Dofs? thanks a lot. Regards, Yujie |
From: Roy S. <roy...@ic...> - 2008-11-21 21:06:00
|
On Thu, 20 Nov 2008, Yujie wrote: > I notice that if i need to add vectors in LinearImplicitSystem using > System::add_vector() it must be done before System::init(). However, I can't > confirm the vector number at the beginning. How to dynamically add vectors? Try the following patch, and let me know if it works; if so I'll commit it to SVN. Index: src/solvers/system.C =================================================================== --- src/solvers/system.C (revision 3160) +++ src/solvers/system.C (working copy) @@ -493,21 +493,17 @@ return *(_vectors[vec_name]); } - // We can only add new vectors before initializing... - if (!_can_add_vectors) - { - std::cerr << "ERROR: Too late. Cannot add vectors to the system after initialization" - << std::endl - << " any more. You should have done this earlier." - << std::endl; - libmesh_error(); - } - - // Otherwise build the vector and return it. + // Otherwise build the vector NumericVector<Number>* buf = NumericVector<Number>::build().release(); _vectors.insert (std::make_pair (vec_name, buf)); _vector_projections.insert (std::make_pair (vec_name, projections)); + // Initialize it if necessary + if (!_can_add_vectors) + { + buf->init (this->n_dofs(), this->n_local_dofs()); + } + return *buf; } > In addition, In the same LinearImplicitSystem, the vectors added by > add_vector() have similar characteristics with the variable added by > add_variable(), such as parallel distribution, same Dofs? thanks a lot. Every vector added to a system has dofs for every variable in that system. All vectors have the same indexing and the same parallel distribution. (In particular they're all parallelized like solution, and if you want ghost dof coefficients you'll need to create a local vector to hold them) --- Roy |
From: Yujie <rec...@gm...> - 2008-11-23 06:44:24
|
Dear Roy: I don't sorry that I don't understand the second problem. To my knowledge, if I use add_variable() to add the variables, these variables will add dofs, right? If I use add_vector() to add the vectors, I don't specify the purpose of the vectors and they don't add dofs, right? Now, I want to copy the solution (variables) to the vectors(added by add_vector()), why do I need to create the local vector? why not just use the vectors added by add_vector()? it doesn't work? thanks a lot. Regards, Yujie > > > > In addition, In the same LinearImplicitSystem, the vectors added by >> add_vector() have similar characteristics with the variable added by >> add_variable(), such as parallel distribution, same Dofs? thanks a lot. >> > > Every vector added to a system has dofs for every variable in that system. > All > vectors have the same indexing and the same parallel distribution. (In > particular they're all parallelized like solution, and if you want ghost > dof > coefficients you'll need to create a local vector to hold them) > --- > Roy > |
From: Roy S. <roy...@ic...> - 2008-11-23 19:06:19
|
On Sat, 22 Nov 2008, Yujie wrote: > I don't sorry that I don't understand the second problem. To my knowledge, > if I use add_variable() to add the variables, these variables will add dofs, > right? Right. > If I use add_vector() to add the vectors, I don't specify the > purpose of the vectors and they don't add dofs, right? Right; each new vector has a coefficient corresponding to each existing dof. > Now, I want to copy the solution (variables) to the vectors(added by > add_vector()), why do I need to create the local vector? You don't need to create anything to copy the solution to the new vectors. But if you want to copy the current_local_solution to the new vectors, it won't work, because the new vectors only have storage for local dof coefficients, not for ghost dof coefficients. --- Roy |
From: Yujie <rec...@gm...> - 2008-11-24 17:42:44
|
Dear Roy: I am sorry to further bother you. Howeve, I have read the patch you provided to me. I think I didn't demonstrate my problem detailedly. I need to dynamically add vectors after System::init(). However, regarding the patch, I think it only is for before System::init(), right? Because if System::init() is implemented, the program will generate errors in the following codes to my knowledge " - // We can only add new vectors before initializing... - if (!_can_add_vectors) - { - std::cerr << "ERROR: Too late. Cannot add vectors to the system after initialization" - << std::endl - << " any more. You should have done this earlier." - << std::endl; - libmesh_error(); - } " thanks a lot. Regards, Yujie On Fri, Nov 21, 2008 at 1:05 PM, Roy Stogner <roy...@ic...>wrote: > > On Thu, 20 Nov 2008, Yujie wrote: > > I notice that if i need to add vectors in LinearImplicitSystem using >> System::add_vector() it must be done before System::init(). However, I >> can't >> confirm the vector number at the beginning. How to dynamically add >> vectors? >> > > Try the following patch, and let me know if it works; if so I'll commit it > to SVN. > > > Index: src/solvers/system.C > =================================================================== > --- src/solvers/system.C (revision 3160) > +++ src/solvers/system.C (working copy) > @@ -493,21 +493,17 @@ > return *(_vectors[vec_name]); > } > > - // We can only add new vectors before initializing... > - if (!_can_add_vectors) > - { > - std::cerr << "ERROR: Too late. Cannot add vectors to the system > after initialization" > - << std::endl > - << " any more. You should have done this earlier." > - << std::endl; > - libmesh_error(); > - } > - > - // Otherwise build the vector and return it. > + // Otherwise build the vector > NumericVector<Number>* buf = NumericVector<Number>::build().release(); > _vectors.insert (std::make_pair (vec_name, buf)); > _vector_projections.insert (std::make_pair (vec_name, projections)); > > + // Initialize it if necessary > + if (!_can_add_vectors) > + { > + buf->init (this->n_dofs(), this->n_local_dofs()); > + } > + > return *buf; > } > > > In addition, In the same LinearImplicitSystem, the vectors added by >> add_vector() have similar characteristics with the variable added by >> add_variable(), such as parallel distribution, same Dofs? thanks a lot. >> > > Every vector added to a system has dofs for every variable in that system. > All > vectors have the same indexing and the same parallel distribution. (In > particular they're all parallelized like solution, and if you want ghost > dof > coefficients you'll need to create a local vector to hold them) > --- > Roy > |
From: Roy S. <roy...@ic...> - 2008-11-24 20:09:14
|
On Mon, 24 Nov 2008, Yujie wrote: > I am sorry to further bother you. Howeve, I have read the patch you provided > to me. I think I didn't demonstrate my problem detailedly. You demonstrated your problem, correctly; you just didn't understand the "diff" format of the patch I provided. The lines with "-" in front of them are lines from the existing code which the patch *removes*. See the "patch" command for details. If you can't get it to work, I'll send you a complete .C file when I'm done traveling. --- Roy |
From: Yujie <rec...@gm...> - 2008-11-25 00:02:39
|
Dear Roy: I am checking the codes about the output file. If using the method you provide, one can't simultaneously output the variable and vector in a file, right? Because the vectors are the copies of the solutions in my application, I am considering to refer to build_variable_names() and build_solution_vector() to write two functions (build_vector_names() and build_vector_vector()) to output the vector values. I feel it should be simple. could you give me some comments? thanks a lot. Regards, Yujie On Mon, Nov 24, 2008 at 3:51 PM, Roy Stogner <roy...@ic...>wrote: > On Mon, 24 Nov 2008, Yujie wrote: > > In addition, how to write the vectors added by add_vector() to the output >> files (such as gmv, tecplot formats)? >> > > Swap the solution and the added vector, write the solution, swap back. > --- > Roy > |
From: Roy S. <roy...@ic...> - 2008-12-10 18:37:14
|
Sorry, did I not get back to you on this yet? On Mon, 24 Nov 2008, Yujie wrote: > I am checking the codes about the output file. If using the method you > provide, one can't simultaneously output the variable and vector in a file, > right? Right. You'd have to have a separate gmv (or whatever) file for each output format. > Because the vectors are the copies of the solutions in my application, I am > considering to refer to build_variable_names() and build_solution_vector() > to write two functions (build_vector_names() and build_vector_vector()) to > output the vector values. I feel it should be simple. could you give me some > comments? thanks a lot. Yes. And after that refactoring, you could rewrite our output code to cause all vectors to be output rather than just the solution. A variable named "concentration" in the vector "old_solution" would be written as "old_solution_concentration" in the output file. For backwards compatibility's sake (and so as to not annoy the many users whose only extra vector is an old_solution they don't care to output) it would be good if this was optional and not default behavior. But with that quibble, we'd certainly be happy to accept such a patch. By the way (and this is what got me looking through old emails from you in the first place), did you apply and test that "dynamic vector addition" patch yet? I'd like to commit it to SVN if it works correctly. Thanks, --- Roy |
From: Yujie <rec...@gm...> - 2008-12-10 18:59:18
|
Dear Roy: I think you are busy and can't reply me. it is fine. I have tested the dynamic vector addition in sequential mode. It works for me. I think it should be work for parallel. Regarding outputing dynamic vector, I have writing some codes for it. However I didn't finish it. Because the output final vector containing all the solutions is variable-major. if there are multiple variables in one System, large change should be done in output function. In addition, the FE type of dynamic vectors is another problem. I am very happy to continue finishing this patch. Could you give me some advice about the above worry. thanks a lot. Regards, Yujie On Wed, Dec 10, 2008 at 10:37 AM, Roy Stogner <roy...@ic...>wrote: > > Sorry, did I not get back to you on this yet? > > On Mon, 24 Nov 2008, Yujie wrote: > > I am checking the codes about the output file. If using the method you >> provide, one can't simultaneously output the variable and vector in a >> file, >> right? >> > > Right. You'd have to have a separate gmv (or whatever) file for each > output format. > > Because the vectors are the copies of the solutions in my application, I >> am >> considering to refer to build_variable_names() and build_solution_vector() >> to write two functions (build_vector_names() and build_vector_vector()) to >> output the vector values. I feel it should be simple. could you give me >> some >> comments? thanks a lot. >> > > Yes. And after that refactoring, you could rewrite our output code to > cause all vectors to be output rather than just the solution. A > variable named "concentration" in the vector "old_solution" would be > written as "old_solution_concentration" in the output file. > > For backwards compatibility's sake (and so as to not annoy the many > users whose only extra vector is an old_solution they don't care to > output) it would be good if this was optional and not default > behavior. But with that quibble, we'd certainly be happy to accept > such a patch. > > > By the way (and this is what got me looking through old emails from > you in the first place), did you apply and test that "dynamic vector > addition" patch yet? I'd like to commit it to SVN if it works > correctly. > > Thanks, > --- > Roy > |
From: Roy S. <roy...@ic...> - 2008-12-10 19:42:28
|
On Wed, 10 Dec 2008, Yujie wrote: > I think you are busy and can't reply me. it is fine. Close; the situation wasn't "busy and can't", just "busy and forgot to". Sorry. > I have tested the dynamic vector addition in sequential mode. It > works for me. I think it should be work for parallel. Thanks! I'll add it to SVN now. > Regarding outputing dynamic vector, I have writing some codes for it. > However I didn't finish it. Because the output final vector containing all > the solutions is variable-major. if there are multiple variables in one > System, large change should be done in output function. I see what you mean. It wouldn't be a trivial patch. > In addition, the FE type of dynamic vectors is another problem. This shouldn't be a problem - dynamic vectors are allocated the same way the solution vector is, and each variable in each dynamic vector should have exactly the same FE type as the corresponding variable in the solution. --- Roy |
From: Yujie <rec...@gm...> - 2008-12-10 22:33:41
|
Regarding the FE type of the dynamic vector, to my application, it is from the solution vector. However, to other applications, we don't know whether the users use it to save the old solution. If the users use the vectors added by add_vector() to save other values, it will generate unpredictable results, right? Yujie On Wed, Dec 10, 2008 at 11:42 AM, Roy Stogner <roy...@ic...>wrote: > > On Wed, 10 Dec 2008, Yujie wrote: > > I think you are busy and can't reply me. it is fine. >> > > Close; the situation wasn't "busy and can't", just "busy and forgot > to". Sorry. > > I have tested the dynamic vector addition in sequential mode. It >> works for me. I think it should be work for parallel. >> > > Thanks! I'll add it to SVN now. > > Regarding outputing dynamic vector, I have writing some codes for it. >> However I didn't finish it. Because the output final vector containing all >> the solutions is variable-major. if there are multiple variables in one >> System, large change should be done in output function. >> > > I see what you mean. It wouldn't be a trivial patch. > > In addition, the FE type of dynamic vectors is another problem. >> > > This shouldn't be a problem - dynamic vectors are allocated the same > way the solution vector is, and each variable in each dynamic vector > should have exactly the same FE type as the corresponding variable in > the solution. > --- > Roy > |
From: Roy S. <roy...@ic...> - 2008-12-10 22:59:38
|
On Wed, 10 Dec 2008, Yujie wrote: > Regarding the FE type of the dynamic vector, to my application, it is > from the solution vector. In *every* application it is the same FE type as the solution vector. That's how the library decides how many degrees of freedom to allocate, how to project the solutions when there's mesh refinement, and so on. If another application is trying to store non-FEM data with add_vector(), that's their bug and the library doesn't need to worry about it. > However, to other applications, we don't know > whether the users use it to save the old solution. If the users use the > vectors added by add_vector() to save other values, it will generate > unpredictable results, right? Whether the output is physically meaningful and important is up to the user, true, but it would never be unpredictable. --- Roy |