[Hugoles]

Dear all,

I have a domain with a U field for which I need to map planes (perpendicular to the flow direction) to a plane within another domain. Specifically, every plane along the flow direction of the U field in the first domain is copied into a plane in a second domain at every time-step. I understand that one way to do something similar is by sampling the planes of the first domain, saving them and later plug them in the second domain at the inlet by using timeVaryingMappedFixedValue boundary condition. However, what I need is actually to map only a section of each of the planes of the first domain not to the inlet, but to a plane at a certain position inside the second domain, also for every time-step. Interpolation should not be an issue as the number of cells as well as their size is the same in each region.

Does anybody knows how to to this? Seems to me that swak4Foam should be able to do this, but I don't know how (one of the reasons is that the region in the second domain is not a patch, when I'm thinking of groovyBC). Furthermore, using swak maybe there is even a more "direct" way, this is, to sample the planes from the first domain at the same time they're being transported in the second domain.

Any thoughts?

Thank you,

Hugo

[gschaider]

Originally Posted by Hugoles

I have a domain with a U field for which I need to map planes (perpendicular to the flow direction) to a plane within another domain. Specifically, every plane along the flow direction of the U field in the first domain is copied into a plane in a second domain at every time-step. I understand that one way to do something similar is by sampling the planes of the first domain, saving them and later plug them in the second domain at the inlet by using timeVaryingMappedFixedValue boundary condition. However, what I need is actually to map only a section of each of the planes of the first domain not to the inlet, but to a plane at a certain position inside the second domain, also for every time-step. Interpolation should not be an issue as the number of cells as well as their size is the same in each region.

Does anybody knows how to to this? Seems to me that swak4Foam should be able to do this, but I don't know how (one of the reasons is that the region in the second domain is not a patch, when I'm thinking of groovyBC). Furthermore, using swak maybe there is even a more "direct" way, this is, to sample the planes from the first domain at the same time they're being transported in the second domain.

So you want to to sample from one plane to another plane which is not a boundary patch? How do want to set the values there? By fixing the values in the cells (you can't do that on that non-boundary faces)? swak currently does not support general interpolation from one entity (in your case that would be a sampledSurface or a faceZone) to another (probably a cellSet). Currently for external variables in the general case only homogenous values are supported. If that WOULD work then using the forceEquation-class (that would have to be built into the solver) or manipulateField-functionObject (that would be rather ugly) you could set the values there.

What could work (but I don't fully understand what you're trying to do - a sketch would be helpful) is the directMappedPatch (or mappedPatch. Name depends on the OpenFOAM-version) which allows to map the values from cells in one region to a patch. You'd have to introduce a pair of patches (a baffle) at the place where you want to interpolate the values TO and then with the appropriate boundary conditions (but I can't comment on that without knowing what the actual physical problem is) it could work. Even without swak.

Where the current version of swak in the development-repository (Not the release) can help you is that it now allows on a directMapped/mapped-patch with a function "mapped(T)" to access the mapped values. Also external variables that access the mapped patch are now non-homogenous. Also a utility calcNonUniformOffsetsForMapped that allows setting the sampling offsets. Currently only docu for all this is the README and the cases in Examples/test with mapped in the name

[Hugoles]

Hello Bernhard,

Thanks a lot for your quick and thorough answer. So, the actual problem goes like this: I'm simulating the wake of a wind turbine, so I have a domain where the rotor is simulated using transient source (rather sink) terms in the momentum equation. I'm interested in the influence that the turbulence in the incoming wind flow produces on the wake of the rotor, so I need to create a turbulence field in a precursor mesh. For a number of reasons I create the turbulence field using matlab but the values of the U field as well as the mesh are converted to an OF case that I can manipulate. In this turbulence field, each cell in the streamwise direction in space corresponds to a time-step in the domain that contains the rotor. Thus, I have a precursor domain containing as many cells in the longitudinal direction as time-steps I want to simulate in the domain with the rotor. So, what is needed is to sample planes perpendicular to this streamwise direction in the turbulent field and introduce them into the domain where the wake is simulated, at a certain distance d from the rotor (as in the attached figure). The planes are not introduced at the inlet since there is no production of turbulence in the domain with the rotor, so the turbulence will decay as it moves with the wind flow (x-direction) and this effect is attenuated by introducing the turbulence close to the rotor. Moreover, these planes do not cover the whole cross-section of the rotor domain (y-z planes in the drawing) as only the cells in the central region are uniform (rotor is located there). Cells are stretched towards the boundaries so turbulence (which is generated in a uniform mesh) should not be mapped into those zones. Ideally, the turbulence planes should be inserted by using source term (analogous to the rotor) and also Gaussian-distributed along some cells to avoid continuity problems. But for now, the direct use of the velocity should suffice.

Therefore, what I need to map are the values of the cell centers from one plane to another. cellSet should work to select the region ahead of the rotor, but the planes of the U field are obviously non-homogenous. However, I could modify the mesh so that this region corresponds to a surface where mesh blocks are connected and in this way, a pair of patches can be defined. In that case, the cell centers of the turbulence planes would have to be interpolated into cell faces, which I'm not sure how good it would work. On the other hand, the good news is that if I can access the non-uniform mapped values with swak, they can be "easily" manipulated and that could be very helpful when the turbulence is introduced using a source term.

What do you think? Will it be possible to map the cell values of the planes into the planes ahead of the rotor? Or could I use any other mapping solution even though the field is non-uniform?

Thanks a lot again,

Hugo

[gschaider]

Originally Posted by Hugoles

Hello Bernhard,

Thanks a lot for your quick and thorough answer. So, the actual problem goes like this: I'm simulating the wake of a wind turbine, so I have a domain where the rotor is simulated using transient source (rather sink) terms in the momentum equation. I'm interested in the influence that the turbulence in the incoming wind flow produces on the wake of the rotor, so I need to create a turbulence field in a precursor mesh. For a number of reasons I create the turbulence field using matlab but the values of the U field as well as the mesh are converted to an OF case that I can manipulate. In this turbulence field, each cell in the streamwise direction in space corresponds to a time-step in the domain that contains the rotor. Thus, I have a precursor domain containing as many cells in the longitudinal direction as time-steps I want to simulate in the domain with the rotor. So, what is needed is to sample planes perpendicular to this streamwise direction in the turbulent field and introduce them into the domain where the wake is simulated, at a certain distance d from the rotor (as in the attached figure). The planes are not introduced at the inlet since there is no production of turbulence in the domain with the rotor, so the turbulence will decay as it moves with the wind flow (x-direction) and this effect is attenuated by introducing the turbulence close to the rotor. Moreover, these planes do not cover the whole cross-section of the rotor domain (y-z planes in the drawing) as only the cells in the central region are uniform (rotor is located there). Cells are stretched towards the boundaries so turbulence (which is generated in a uniform mesh) should not be mapped into those zones. Ideally, the turbulence planes should be inserted by using source term (analogous to the rotor) and also Gaussian-distributed along some cells to avoid continuity problems. But for now, the direct use of the velocity should suffice.

Therefore, what I need to map are the values of the cell centers from one plane to another. cellSet should work to select the region ahead of the rotor, but the planes of the U field are obviously non-homogenous. However, I could modify the mesh so that this region corresponds to a surface where mesh blocks are connected and in this way, a pair of patches can be defined. In that case, the cell centers of the turbulence planes would have to be interpolated into cell faces, which I'm not sure how good it would work. On the other hand, the good news is that if I can access the non-uniform mapped values with swak, they can be "easily" manipulated and that could be very helpful when the turbulence is introduced using a source term.

What do you think? Will it be possible to map the cell values of the planes into the planes ahead of the rotor? Or could I use any other mapping solution even though the field is non-uniform?

Thanks a lot again,

Hugo

The only way in swak (not 100% sure if there are other ways in OpenFOAM) to get anything inhomogenous going is to have a baffle (two patches) at the place of the turbulence generator and at least the downwind patch being a mapped patch. That patch can map from cells of another solution. But here comes the bummer: the offset of these cells is fixed in time (even if swak wanted this to be transient I'm not sure whether the underlying OF-mechanism supports it) and if I understand you correctly you wish to "sweep" through the volume. So: close, but no cigar. I don't think that swak in its present form can do it

Have you checked timeVaryingMappedFixedValueFvPatchField in OF? Maybe that is more what you want. You'll need a patch for that to and do a different conversion for the MATLAB-data. But I never worked with that BC

[Hugoles]

Hello Bernhard,

Thanks a lot for your reply. It's been some time since the last post but I thought I should make some test before replying and I did not do it until recently. What is more, I thought that setting the baffle to timeVaryingMappedFixedValue to import the sampled U field will solve the problem more or less straightforwardly. But that's never the case.

The issue is that I want to "add" the imported U plane to the local field in the domain where I perform the calculations, i.e. to impose the turbulence field on the laminar field coming from the inlet. But if the downwind side of the baffle is set to timeVaryingMappedFixedValue, how could I make that boundary completely porous to the inflow velocity? Moreover, I am not so sure what to prescribe at the baffle for the other variables (e.g nuSgs, p) so it does not alter their values. On the other hand, following the use of the fan patch, it would make sense to set the baffle to cyclic for all the other variables except U, which obviously could no longer be defined as timeVaryingMappedFixedValue at the same time.

But coming back to swak, in spite of what you have said regarding the non-uniform field support, will it be possible, perhaps, to use a groovy BC and set the baffle to timeVaryingMappedFixedValue PLUS the value of the U field at the position of the patch (or the previous cell centers)? I know is bold but I am running out of ideas about how to import the field to the baffle while making it transparent to the fields.

Thanks a lot for all the help,

Hugo

[gschaider]

Originally Posted by Hugoles

Hello Bernhard,

Thanks a lot for your reply. It's been some time since the last post but I thought I should make some test before replying and I did not do it until recently. What is more, I thought that setting the baffle to timeVaryingMappedFixedValue to import the sampled U field will solve the problem more or less straightforwardly. But that's never the case.

The issue is that I want to "add" the imported U plane to the local field in the domain where I perform the calculations, i.e. to impose the turbulence field on the laminar field coming from the inlet. But if the downwind side of the baffle is set to timeVaryingMappedFixedValue, how could I make that boundary completely porous to the inflow velocity? Moreover, I am not so sure what to prescribe at the baffle for the other variables (e.g nuSgs, p) so it does not alter their values. On the other hand, following the use of the fan patch, it would make sense to set the baffle to cyclic for all the other variables except U, which obviously could no longer be defined as timeVaryingMappedFixedValue at the same time.

But coming back to swak, in spite of what you have said regarding the non-uniform field support, will it be possible, perhaps, to use a groovy BC and set the baffle to timeVaryingMappedFixedValue PLUS the value of the U field at the position of the patch (or the previous cell centers)? I know is bold but I am running out of ideas about how to import the field to the baffle while making it transparent to the fields.

Thanks a lot for all the help,

Hugo

Have you tried the jump-boundary condition (for an example using groovyBC see Examples/test/jumpChannel)? That would be cylic for everything except the variable you specify.

But I've never used that for imposing a jump on the velocity. Value "at next cell center" would be internalField(U) but you'll have to experiment how to get that from "the other side" (neighbourField(U) would be the patch-value for that, but I don't think there is such a function for internalField ... hold on. I read doxygen. Seems neighbourField IS the internalField of the neighbour. But you'd have to check that).

I don't think that a cyclic patch (which is prerequisite for a jump) can be directMapped at the same time (but you'd have to try that to be sure) which if I remember it correctly would be what you wanted in the first place

[Hugoles]

Hello Bernhard,

Thanks for the reply. I have not tried the jumpBC, I missed that one. If I understand correctly, that would work as long as long as I could "add" the U field brought in by the timeVaryingMappedFixedValue to the neighbourField. Will the fields let themselves to be manipulated in such way? I'll have to try it.

For the time being, I use an advective BC for all the fields at the downwind patch and a mapped BC for those at he upwind (except U). I import the U fields using timeVaryingMappedFixedValue at the downwind patch. This does not do exactly what I wanted as the U field is imposed as is, instead of importing a U field containing only fluctuations and add them to the local U field at the baffle location. Therefore, some blockage/discontinuity effects could be expected. Nevertheless, preliminary tests don't look too bad, so far.

Thanks,

Hugo