>> May I ask if something of the proposed kind will be implemented
>> anytime soon? If not, I will have to continue using my own hacked
>> "branch" of libmesh instead of the trunk... ;-)
>
> Probably not soon. I hate the idea of leaving you stuck on a
> permanently forked branch, though...
>
> Perhaps we could avoid using a sequential PRNG in distort()
> altogether? Replace the std::rand() subroutine calls with some kind
> of function calls that lack internal state, just hashing the initial
> seed with the previous node coordinates somehow?
Is the question can the user-specified seed patch be applied, or can the
distort functionality be made to work properly on parallel meshes?
The former should not be a problem - the latter we should trap for with an
assert, but doesn't seem to be a major priority, right? Reasonably sized
meshes could be distorted in serial as a preprocessing step?
So I think we can immediately accommodate the patch – it certainly does no harm
– am I missing something?
-Ben
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
