Actuator line with FSI

[nalucfd]

Actuator line with FSI

[mchurchf]

@spdomin:
@gantech and I have identified something that we need to reorganize in the actuator line execute function. The way it is currently set up, the first thing that happens is that if there is motion, the blades get moved and all the ghosting information gets updated by calling initialize(). Then the velocity is sampled in this new location, forces computed, and forces applied to the source term.

There is a problem with this. Along the actuator line, because it is a lifting line, it creates a bound vortex with its axis along the line. The velocity that we sample is supposed to be the "freestream" velocity. That is a fuzzy thing with a rotor, but the main point is that you don't want to sample any of the upwash or downwash of the bound vortex. There are a few options, but I think the most convenient is to sample right smack in the center of the bound vortex where its own induced velocity is zero, so you are sampling the "freestream". If you move the line, and then sample, you're moving the line away from the center of the bound vortex, and then you sample some of the upwash. It would only work if there was some sort of subiterations going on in which the actuator line forces kept getting updated during the subiterations because the bound vortex would move, too. But here, the line is being treated explicitly in time. It makes a significant difference in the lift you end up computing. So, it is better to keep the blade where it last was, sample the velocity, then move it, and then apply the force.

I know this is getting long... But, I don't think this is as simple as moving the initialize() function call down in the execute command. Because there is a parallel_sum_including_ghosts() call at the end to sum up all the contributions to the source term, I'm thinking it is not okay to change the ghosting midway through execute by moving the initialize() function call downward. See what I'm saying? Any thoughts?

[mchurchf]

Pasting in what @gantech wrote by email:

Hello,

I’m starting a conversation reg. an issue Matt C bought up on github.

My comments:

Matt is talking about lines near 524 in ActuatorLine.C in the integrateFAST branch (https://github.com/gantech/Nalu/blob/integrateFAST/src/ActuatorLine.C#L524). I see that the execute function parallel communicates coordinates, velocity and viscosity fields before line 524 here.

// parallel communicate data to the ghosted elements; again can communicate points to element ranks
if ( NULL != actuatorLineGhosting_ ) {
std::vector< const stk::mesh::FieldBase _> ghostFieldVec;
// fields that are needed
ghostFieldVec.push_back(coordinates);
ghostFieldVec.push_back(velocity);
ghostFieldVec.push_back(viscosity);
stk::mesh::communicate_field_data(actuatorLineGhosting, ghostFieldVec);
}

The new call to initialize near line 524 will destroy (and recreate? this ghosting in manage_ghosting()?) As I understand it, only the actuator_line_source and actuator_line_source fields are affected between line 524 and the call to parallel_sum_including_ghosts() at the end of the execute function. Is my understanding correct?

ganesh

[mchurchf]

@spdomin and @gantech:

An update on the above. I went ahead and moved things around in the original actuator line code (not Ganesh's integrate FAST branch), to sample at the old line location, and then move the line, and it all runs fine, but I need to test and make sure everything is really working okay. @spdomin if you could comment on what Ganesh more clearly articulated than I did, that would be helpful.

[spdomin]

This effort has been transitioned to Jira.