|
|
|
|
|
NoMotion.png (51,314 bytes) |
|
|
MovingMesh_ActualDev.png (76,851 bytes) |
|
|
MovingMesh_Updated.png (56,325 bytes) |
|
|
|
|
|
Hi all, I was thinking about the patch and found some inconsistency. I expected that one starts with the static solver (such as pimpleFoam) and change to the dynamic one afterwards (such as pimpleDyMFoam). However, if one starts directly with the dynamic solver, we have to ensure that the angle is zero up to the time the rotation starts. I changed that and attached the updated rotating motion class. Tobi |
|
|
I haven't looked at the patch (so don't know if this is relevant) but just wanted to make you aware of a commit from 2 days ago: https://github.com/OpenFOAM/OpenFOAM-dev/commit/9c4804 Making pimpleDyMFoam "exactly equivalent to pimpleFoam when running on a staticFvMesh" enables consolidation of static and dynamic motion solvers (into one). So base your ideas on running everything on the *DyM* solver, which sounds like what you have done in your follow up note. |
|
|
@Chris, thanks for the info. I was not checking the latest commits in the dev line the last days. I checked the commit and it seems to be a nice one. However, the issue I am pointing towards is related to the rotatingMotion library. Thanks for your hint again. Tobi |
|
|
Hard-coding a start-time in the rotatingMotion is rather inflexible, it would be also be useful to provide support for ramping for example. One option would be to provide a prefactor Function1 which could then be specified as a Heaviside function instead of a hard-coded start-time but could also be specified as a linear function or any other ramp. However this kind of start offset, ramping etc. is not consistent with the omega integration approach currently used and it might be better to specify the angle directly as a Function1 and then the general ramping and multiplication functionality already provided by Function1 could be used and rotatingMotion would not need an additional Function1. |
|
|
Till now the start-time was hard coded and always started at t = 0. Therefore I made the patch to specify it. The idea specifying a function for omega is a nice idea and would make it much more flexible. I think we should include it too before patching it. I will checkout function1 as you suggested. |
|
|
> The idea specifying a function for omega omega is already a Function1 but because it is integrated it cannot be ramped. So the options are to provide an additional ramping prefactor Function1 or change the omega specification to an angle specification. Probably having an optional ramping prefactor will be more convenient and backward compatible. |
|
|
Got it. So it is actually similar to my project I am working on my PhD. Here I ramp the LASER power based on a pre-factor. I will implement it and attach it here afterwards. |
|
|
Given that omega is integrated and cannot be ramped it might as well be specified as a constant and then an optional Function1 specified as a prefactor. |
|
|
Pending patch |
- Anonymous
