From: Kirk, B. (JSC-EG311) <ben...@na...> - 2013-05-24 14:18:39
|
Put another way, solution contains storage for remote entries but it cannot keep them in sync under all usage cases (1) for performance reasons and (2) to avoid parallel deadlocks. So depending on when you are accessing it the remote values may be stale, leading to chaos. -Ben On May 24, 2013, at 9:08 AM, "Derek Gaston" <fri...@gm...> wrote: > What are you trying to do? There are many scenarios where this could > fail... and some where it might succeed. > > Derek > > Sent from my iPad > > On May 24, 2013, at 8:02 AM, Manav Bhatia <bha...@gm...> wrote: > >> >> >> On May 24, 2013, at 9:58 AM, Derek Gaston <fri...@gm...> wrote: >> >>> Yes. >>> >>> Ok, well, MeshFunction itself doesn't care (as you found out)... but >>> if you want to evaluate your solution in elements containing >>> off-processor degrees of freedom then you need to serialize that >>> vector. >> >> >> But if the element is on a given processor, then wouldn't the local portion of system.solution contain all the relevant dofs to calculate the solution on that element? >> >> If so, then passing it the system.solution should be alright. No? >> >> >>> Think of it this way: MeshFunction doesn't do parallel >>> communication... you are responsible for feeding it the values you >>> need. >>> >>> Derek >>> >>> Sent from my iPad > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users |