Safely setting the solution vector

[rebpoli]

Hi

I am wondering whether it is safe to set the solution vector directly without the "first_local_index" and the "last_local_index" bounds.

Something like:

    for (const auto & elem : mesh.active_local_element_ptr_range())
    {
      vector<dof_id_type> dofs;
      sys.get_dof_map().dof_indices (elem, dofs, t_var);
      for ( uint dof : dofs )
        sys.solution->set( dof, config.temperature_step );
    }

If I set only in a subset of the elements, adding the bounds (see below) prevents some nodes to be set:

      if ((sys.solution->first_local_index() <= dof) && (dof <= sys.solution->last_local_index()))
            sys.solution->set( dof, config.temperature_step );

Note that the element sobdomain controls if its nodes shall be set or not.
Anyways, removing the bounds work - but is it safe?

Renato

[dknez]

In the case that we're using PETSc, then the solution vector is a PETSc vector. In this case you can set non-local entries of a vector, and then when you call close(), it will do the necessary communication so that all processors have the relevant local values only.

But actually, you're asking about a simpler case. You're looping over local elements only and asking if you need to check first_local_dof/last_local_dof when you set vector values. It should work either way, but I think it's better to include the first_local_dof/last_local_dof check, since that will skip setting off-processor values that don't need to be set.

The case to keep in mind is when you have a node that's on the border to the partition of two processors, so that node will be encountered by two processors, but the DOFs on the node belong to only one of the processors. In this case you only need to set the value on the processor that "own" the DOFs, and if you include the first_local_dof/last_local_dof check, then it will skip setting the values on the other processor.

So in summary, it should work either way, but using the first_local_dof/last_local_dof check makes it more clear about which dofs you're setting on which processor. (There would perhaps also be a performance benefit of skipping setting off-processor values, but I assume that is a negligible cost.)

[rebpoli]

That makes sense. Thank you, Renato

…

On Mon, Dec 2, 2024 at 2:26 PM David Knezevic ***@***.***> wrote: In the case that we're using PETSc, then the solution vector is a PETSc vector. In this case you can set non-local entries of a vector, and then when you call close(), it will do the necessary communication so that all processors have the relevant local values only. But actually, you're asking about a simpler case. You're looping over local elements only and asking if you need to check first_local_dof/last_local_dof when you set vector values. It should work either way, but I think it's better to include the first_local_dof/last_local_dof check, since that will skip setting off-processor values that don't need to be set. The case to keep in mind is when you have a node that's on the border to the partition of two processors, so that node will be encountered by two processors, but the DOFs on the node belong to only one of the processors. In this case you only need to set the value on the processor that "own" the DOFs, and if you include the first_local_dof/last_local_dof check, then it will skip setting the values on the other processor. So in summary, it should work either way, but using the first_local_dof/last_local_dof check makes it more clear about which dofs you're setting on which processor. (There would perhaps also be a performance benefit of skipping setting off-processor values, but I assume that is a negligible cost.) — Reply to this email directly, view it on GitHub <#4028 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMOVERZXNSHPSAPD3NU7SVL2DS65NAVCNFSM6AAAAABS4HGHMOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNBUGA4DSNQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>