if just one body, simulate in body-fixed frame to precompute matrices (and account for fictitious forces)

[jcallaham]

Reading about this a bit in Steve's thesis.. does this definitely require fictitious forces? Both C++ and Fortran codes seem to implement with just a time-varying base flow, though I need to think about why you wouldn't need Coriolis, etc. in the momentum equations

[ajgoza]

Honestly I've never looked through the details of this. Let me look into this a bit and followup...

[jcallaham]

Looks like it is just a matter of (1) replacing the constant base flux with a time-varying one and (2) calculating the correct velocity for all the surface points. I think it shouldn't be too bad, since we have some of the scaffolding already. Here's my plan:

• [x] Implement for pure rotation and compare to the RotatingCyl benchmark
• [x] Same for pure translation (since body velocity is easy in that case)
• [ ] Use the TangentSE2 transformations to get body velocity for arbitrary motions
• [x] Move from specifying rotation and translation to a function that gives body-center position & velocity

[ajgoza]

That sounds like a great plan. And just to confirm -- I'm pretty sure that after performing the steps you described, the surface stresses (and resulting lift and drag) will be the values for the desired problem in a lab-frame with the body moving, rather than the body-frame force absent the appropriate "fictitious forces". But would be good to check. I'll try to code up some plotting functionality for CL and CD to make that comparison a little easier

[jcallaham]

Cool, that's also my understanding, based on the $u_n$ notation in Hsieh-Chen's thesis.

I started a new "body-fixed" branch to work on this stuff this weekend - hopefully I can get something up and running in the next couple of days.

[jcallaham]

Just pushed some changes that I think add most of the basic functionality. Now you can specify U(t) and Omega(t) for free-stream linear velocity and angular velocity about the origin. Also now I think we don't need the TangentSE2 stuff for the BodyFixed motions, since the "perturbation" velocity (added to time-varying one) should just be zero... I think. @ajgoza correct me if I'm wrong on that.

Still quite a few things left before we can close this out (note for myself):

• Finish validation with rotating cylinder in case where operators are recomputed
• Run benchmark cases in C++ and/or Fortran with moving bodies
• Redo base_flux! with direct cross product (rather than calling circ2_st_vflx, which is relatively expensive... could be a separate issue if this turns out to be difficult)
• Standardize call signatures (base_flux in particular, but check others)
• Full time-series comparison vs C++ or Fortran with a joint pitch/plunge maneuver (e.g. Eldredge)
• Is the rotation/translation specification already the same as position/velocity specification?

[jcallaham]

[ajgoza]

vid looks great! And that's a great list of to dos. One to-do I'd suggest (I can do as part of my cleanup after you've merged your changes) is to allow for a nonzero center of rotation.

agreed, should not need the tangentSE2 stuff for BodyFixed, because all of the update to the velocity should be contained in the potential flux terms. (caveat: will still need for multiple bodies).

Also, I was hoping to get to my cleanup tasks this weekend but it's going to have to wait to this week, or perhaps this coming weekend...

[jcallaham]

Yeah I think that will also be useful. For the time being you can just define the body to be offset from the grid origin, but that wouldn't be helpful for large offsets like the vertical axis turbines. I think it would be easiest to wait on that until I have a chance to move the circulatory base flow computation from circ2_st_vflx! to a cheaper cross product, since the grid coordinates show up explicitly in that case.

I think I got pitching to work as well (or at least the video looks convincing), but I'm going to start working on validation cases today so we can do a quantitative comparison. No rush on the other tasks... it actually might be easier to wait until we can merge this back in with main to avoid conflicts. I'm going to work on validation cases today and hopefully this will be in good shape by the end of the week.

[ajgoza]

That looks awesome!

OK, noted, I hear you about waiting until the cross product is implemented to allow for nonzero center of rotation.

And sure, sounds good about waiting with cleanup. I've actually had a bit of time today to think about how to organizing how data will be saved, so hopefully I can jump into implementing once you've merged your changes. Looking good!

[jcallaham]

Alright, I think this is basically implemented. There are some slight mismatches in the pitch/hold validation case, but I can't tell if this is a bug or just some kind of slight numerical variation. I feel like we should be able to match the "Fortran" line basically perfectly, but I don't have a good sense for this kind of thing. Good news is there's about a 30% speedup over C++ and 25% over the Fortran when all three are in the body-fixed frame! C++(1) and (2) are body-fixed and lab-frame simulations in this:

Anyway, maybe we can talk more about that on Tuesday, but there are significant enough changes here that we may want to just merge back into main and have separate issues for validation and a couple other follow-up things.

[ajgoza]

The speed up is awesome! And the curves are looking pretty good — certainly the gist of the implementation is on the money. I agree that we should be able to match the FORTRAN results exactly. But I also agree that there are enough changes here to merge into master and open a separate issue for validation (with this as a VERY good starting point on that front — looks like the maximum discrepancy is ~10%!)

[jcallaham]

Sounds good, and actually I'm not even positive the issue is with the motion. It seems like there may be some small discrepancy even for static bodies, which could potentially be amplified with this test case.