From: Travis A. <aus...@ya...> - 2006-12-28 00:23:36
|
Hi,=0A=0AI am building reaction-diffusion problems with varying diffusion a= nd reaction coefficients (each node has its own value) =0Aand I am currentl= y reading in these coefficients using MeshData. I've been using MeshData b= ecause I find it is a bit =0Amore natural than using multiple EquationSyste= ms to read in data, which was suggested previously. =0A=0AI originally tri= ed to use MeshData with XTA/XDA mesh formats but ran into a problem that is= not easily fixed. So I've gone =0Ato using UNV mesh files (both for mesh = and data). Everything works in the serial case (reading in mesh and data r= uns and =0AI can access the data) but not in the parallel case. I get the = following error.=0A=0A(*) monodomain_example_aliev: src/mesh/mesh_data.C= :240: void MeshData::read(const std::string&): Assertion `_elem_id_map_clos= ed && _node_id_map_closed' failed.=0A=0AI believe that the problem is that = processor 1 has not closed his elem_id_map or node_id_map which is only don= e by processor =0A0 who reads in the mesh. =0A=0ASee following lines in me= sh.C and unv_io.C=0A=0Amesh.C:719 UNVIO(*this, *mesh_data).read (name)= ;=0A=0Aunv_io.C:260 this->_mesh_data.close_foreign_id_maps ();=0A=0AThis= last line is only performed by processor 0 since only he reads in the mesh= . So when reading in MeshData, processor 1 causes above=0Aerror (*). Even= if this was fixed, it doesn't look like that processor 0 communicates the = MeshData after he reads it in so if this is to work a few=0A(hopefully just= a few) bits need fixed up.=0A=0AMy question is whether or not there is any= long term support for MeshData using either UNV or XDA or any other format= . I'm worried I'm =0Agoing to keep running into problems using MeshData si= nce I've found one using XTA/XDA and now a second using UNV with >1 process= ors. =0AIt seems most people run problems using libMesh where parameters a= re constant so it makes me think that most people don't care about =0Areadi= ng in data to a mesh. I do and I'd like to find something reliable without= redeveloping something completely new. Any thoughts?=0A=0ACheers, Travis = Austin=0A=0A=0A=0A=0A=0A__________________________________________________= =0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the best spam protectio= n around =0Ahttp://mail.yahoo.com |
From: Roy S. <roy...@ic...> - 2006-12-28 04:51:09
|
On Wed, 27 Dec 2006, Travis Austin wrote: > My question is whether or not there is any long term support for > MeshData using either UNV or XDA or any other format. I'm worried > I'm going to keep running into problems using MeshData since I've > found one using XTA/XDA and now a second using UNV with >1 > processors. The trouble with software you don't pay for is often you find out nobody's getting paid for it. ;-) The MeshData classes were written by Daniel Dreyer, who I don't think has been an active libMesh developer in years. The rest of us have made dozens of small changes since to avoid actually breaking that code as libMesh evolves, but as far as I know nobody's actively maintaining it. I don't suppose you want to volunteer? :-) > It seems most people run problems using libMesh where parameters are > constant so it makes me think that most people don't care about > reading in data to a mesh. I do and I'd like to find something > reliable without redeveloping something completely new. Any > thoughts? As far as my own work goes, it's not that the parameters in my equations are constant, it's just that they're usually better expressed either as analytic functions (which I usually just hard-code in C++) or as piecewise polynomial approximations (which end up as additional vectors in my System class or an auxilliary System class in my code). There's probably work to be done no matter what path you take, though. My own apps don't even exercise any restart capability, so for all I know that might only work on Lagrange elements. --- Roy |
From: John P. <pet...@cf...> - 2006-12-28 05:11:41
|
Hi! I'm curious...do you have any idea why the MeshData class refers to it as an xta/xtr file instead of the normal xda/xdr (binary/ascii) file extensions? As far as the MeshData class goes, it is quite possible that it does not work in parallel; this would be the case if the original developers only used it in serial. If you can make the entire class "serial" i.e. wrap more stuff in "if (libMesh::processor_id()==0)", and then communicate the necessary information using the routines similar to those found in mesh_communication.C, that might be enough to get it working. I've done a very small amount of MPI programming, so I might be able to help out if you have a specific question. -John Travis Austin writes: > Hi, > > I am building reaction-diffusion problems with varying diffusion > and reaction coefficients (each node has its own value) and I am > currently reading in these coefficients using MeshData. I've been > using MeshData because I find it is a bit more natural than using > multiple EquationSystems to read in data, which was suggested > previously. > > I originally tried to use MeshData with XTA/XDA mesh formats but > ran into a problem that is not easily fixed. So I've gone to using > UNV mesh files (both for mesh and data). Everything works in the > serial case (reading in mesh and data runs and I can access the > data) but not in the parallel case. I get the following error. > > (*) monodomain_example_aliev: src/mesh/mesh_data.C:240: void > MeshData::read(const std::string&): Assertion `_elem_id_map_closed > && _node_id_map_closed' failed. > > I believe that the problem is that processor 1 has not closed his > elem_id_map or node_id_map which is only done by processor 0 who > reads in the mesh. > > See following lines in mesh.C and unv_io.C > > mesh.C:719 UNVIO(*this, *mesh_data).read (name); > > unv_io.C:260 this->_mesh_data.close_foreign_id_maps (); > > This last line is only performed by processor 0 since only he reads > in the mesh. So when reading in MeshData, processor 1 causes above > error (*). Even if this was fixed, it doesn't look like that > processor 0 communicates the MeshData after he reads it in so if > this is to work a few (hopefully just a few) bits need fixed up. > > My question is whether or not there is any long term support for > MeshData using either UNV or XDA or any other format. I'm worried > I'm going to keep running into problems using MeshData since I've > found one using XTA/XDA and now a second using UNV with >1 > processors. It seems most people run problems using libMesh where > parameters are constant so it makes me think that most people don't > care about reading in data to a mesh. I do and I'd like to find > something reliable without redeveloping something completely new. > Any thoughts? > > Cheers, Travis Austin |