On Wed, 20 Jan 2016, hu.b...@xemail.me wrote: > I am trying to write a programme using infinite elements. Since I am > new to libmesh, please forgive me dumb questions
These are not dumb questions. Please forgive my dumb answers. AFAIK, there are literally zero libMesh developers currently using infinite elements, there haven't been any for several years, and all our infinite element test coverage predates when we started to get serious about regression testing, so the maintenance on infinite element code has been no better than "make sure that it still compiles after its dependencies have been changed". So although it's theoretically *possible* that you're doing something wrong, it's much more likely that our infinite element support is currently broken. > which, in my point of view, is due to an error in inf_elem_builder.C > (see patch in supplement; it seems to solve this problem) Thanks! Our mailing lists tend to strip long (and medium, and insufficiently short) attachments, so I don't see the patch. Would you send me a copy directly? Alternatively you could set up a pull request on Github; this would be a little more work for you but it would make the patch easier to review for us. Plus, if you do the "git commit" yourself then you don't have to rely on us remembering "--author='hu.b...@xemail.me'" to credit you properly. > However, running the code than, gave me several errors: First, the > exodus-output broke down with the message > > "Error: Exodus requires all elements with a given subdomain ID to be the same > type. > Can't write both INFHEX8 and HEX8 in the same block!" Hmm... that's a limitation of our ExodusII output; we use one block per subdomain id, and Exodus doesn't allow more than one element type per block. Perhaps we were originally using GMV in that example, didn't notice when InfElemBuilder regressed, and then that regression masked the problem when we switched from GMV to ExodusII? In any case, the short-term workaround would be to loop over elements and set a new subdomain ID on the infinite ones. In the long term we might want to just add an optional subdomain id argument to InfElemBuilder::build(). > and commenting this line leads to the error > > "Second derivatives for Infinite elements are not yet implemented!" That's actually a warning, not an error, I believe. When an FE object is used without pre-requesting data, it tries to calculate all the data it can, including second derivatives, even though (in miscellaneous_ex11, and in most H1 problem formulations) the second derivatives won't be used later. > however, reinstalling libmesh with the option '--disable-second' > leads to several errors due to inconsistencies (variables are > defined in areas that are excluded but used outside of it We did have a regression there but AFAIK it's been fixed in both master and 0.9.4-rc2. What git revision or release version are you running? Thanks for the helpful bug reports, and for your patience. Send me another copy of your patch and I'll try to get to it by tonight. --- Roy ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
