2017-12-15 23:40 GMT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002764OpenFOAMContributionpublic2017-11-22 10:19
ReporterShorty 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusnewResolutionopen 
PlatformGNU/LinuxOSUbuntuOS Version16.04
Product Versiondev 
Target VersionFixed in Version 
Summary0002764: Extended rotatingMotion class for arbitrary start time
DescriptionHi all,

I realized that the rotatingMotion class does not allow one to start the rotation at an arbitrary time. E.g. the rotation starts at t=2s. So one might run the simulation without any motion for t=2s. After that the rotation starts. However, doing that, one has to start the simulation again at t=0 based on the angle calculation which integrates from t=0:

scalar angle = omega_->integrate(0, t);

I changed the class in order to allow one to start from an arbitrary time (if the startTime keyword is set - otherwise the integration starts at t = 0).

I attached three pictures to demonstrate what I mean and I added the source and header file.


TagsrotatingMotion
Attached Files

-Relationships
+Relationships

-Notes

~0009051

Shorty (reporter)

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

~0009052

chris (manager)

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.

~0009053

Shorty (reporter)

@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

~0009059

henry (manager)

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.

~0009060

Shorty (reporter)

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.

~0009061

henry (manager)

> 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.

~0009062

Shorty (reporter)

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.

~0009063

henry (manager)

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.
+Notes

-Issue History
Date Modified Username Field Change
2017-11-19 01:01 Shorty New Issue
2017-11-19 01:01 Shorty File Added: rotatingMotion.tar.gz
2017-11-19 01:01 Shorty Tag Attached: rotatingMotion
2017-11-19 01:01 Shorty File Added: NoMotion.png
2017-11-19 01:01 Shorty File Added: MovingMesh_ActualDev.png
2017-11-19 01:02 Shorty File Added: MovingMesh_Updated.png
2017-11-19 22:25 Shorty File Added: rotatingMotionUpdated.tar.gz
2017-11-19 22:27 Shorty Note Added: 0009051
2017-11-20 12:37 chris Note Added: 0009052
2017-11-20 13:08 Shorty Note Added: 0009053
2017-11-22 09:36 henry Note Added: 0009059
2017-11-22 09:44 Shorty Note Added: 0009060
2017-11-22 10:02 henry Note Added: 0009061
2017-11-22 10:07 Shorty Note Added: 0009062
2017-11-22 10:19 henry Note Added: 0009063
+Issue History