On Wed, 28 Jun 2017, Salazar De Troya, Miguel wrote:
I just remembered one of the reasons why I left it on hold. It is
because of the partitioning. I will have to keep the same
partitioning on both meshes to avoid high communication costs. The
partitioning criteria should be given by the state
What’s the current functionality for “subactive” elements? Right now, I am only
interested in having the control mesh defined as constant monomial elements,
maybe this special case could be easier to implement. I am not sure how a
lookup table could be an efficient implementation if I want to re
On Tue, 23 May 2017, Salazar De Troya, Miguel wrote:
> I want to use different discretization for the control and the state
> variable in an optimization problem. Is this possible in libMesh?
You can get uniformly different discretizations by using different
finite element types, but for any tru
Hello,
I want to use different discretization for the control and the state variable
in an optimization problem. Is this possible in libMesh? I could imagine that
having two different meshes would be expensive because for each Gaussian point
in the state mesh we would have to find the correspon
Thanks very much Roy, that's done the trick.
Peter
On 16/02/15 17:30, Roy Stogner wrote:
>
> On Mon, 16 Feb 2015, Peter Wijeratne wrote:
>
>> Still having the same problem. I now initialise using the
>> Communicator from LibMeshInit::comm(); is this correct, or should I
>> be creating my own Commu
On Mon, 16 Feb 2015, Peter Wijeratne wrote:
> Still having the same problem. I now initialise using the
> Communicator from LibMeshInit::comm(); is this correct, or should I
> be creating my own Communicators?
No, you'll need to create your own subcommunicators. The communicator
from LibMeshIni
Still having the same problem. I now initialise using the Communicator
from LibMeshInit::comm(); is this correct, or should I be creating my
own Communicators?
Thanks,
Peter
On 09/02/15 20:00, Derek Gaston wrote:
> If you're trying to solve a different problem on each processor you'll
> want t
If you're trying to solve a different problem on each processor you'll want
to create an MPI sub-communicator for each processor and then initialize
the Mesh with that (Note the Mesh constructor that takes a
Parallel::Communicator:
http://libmesh.github.io/doxygen/classlibMesh_1_1Mesh.html ). I be
Thanks for the quick replies!
Roy - I actually do something a bit messy:
SerialMesh* rmsh = new SerialMesh(1);
GmshIO(*rmsh).read(filename.str().c_str());
rmsh->skip_partitioning(true);
rmsh->prepare_for_use();
rmsh->skip_partitioning(false);
rmsh->partition(1);
I f
On Mon, 9 Feb 2015, Peter Wijeratne wrote:
> Bit of a special (as opposed to general) problem here. I'm trying to
> create a serial mesh on each of N processors, each to be kept on its
> respective processor and solved separately.
Are you initializing each Mesh with an appropriate (in this case
There's an assumption that all the processors are working on the same
problem so each processor gets a part of the mesh. Are each of the meshes
truly independent so they don't share any DOFs? If they really are
independent have you considered just running thousands of jobs instead?
Cody
On Mon
Hello libMesh community,
Bit of a special (as opposed to general) problem here. I'm trying to
create a serial mesh on each of N processors, each to be kept on its
respective processor and solved separately. This causes problems when
initialising a given mesh's EquationSystems; I've narrowed the
12 matches
Mail list logo
