launch cases

[d1ma4ek]

Hi Will Yeadon, I am unable to launch a single case. Could you please provide another example case, with two phrases, that you have successfully launched? I would appreciate it if you could include an example of the Lorentz force in your answer. After studying your code and beam Weld Foam, I am still unsure why the weld pool does not go down. It would be helpful if you could also address this issue and explain how the Lorentz force would affect the outcome.

[WillYeadon]

Hi, IIRC all the cases should launch on OpenFOAM 6 with gtawFOAM installed. You should be able to open the cases that have the results loaded in e.g. cases/chpt4-bis- in paraview to see the results without running gtawFOAM. I don't have a setup currently to run the cases myself but the should work on OpenFOAM 6 with gtawFOAM.

Unfortunately the Lorentz force isn't used in gtawFOAM (see page 48 & 79 on the thesis https://arxiv.org/pdf/2205.07687) but in principle you could add in like the T field solving the relevant electromagnetic equation and adding it like a force to the velocity equation. It shouldn't affect the weld pool height much compared to Marangoni & the arc pressure so you'd be safe simulating a flat surface here. There is a breakdown of the effects in Figure 5 in the paper "Numerical analysis of internal flow of molten pool in pulsed gas tungsten arc welding using a fully coupled model with free surface".

As far as simulating the weld pool height, this code doesn't have any sort of arc pressure so the only change in height would come from the Marangoni which in the settings I used itself wasn't strong enough. I was interested in full penetration welds on very small tubes so the inner 'buttressing' force could be set via an internal pressure boundary condition this avoided having to deal with the more complex weld pool surface dynamics from the arc pressure. To be honest I believe that there may be more apt code out there for looking at weld pool height.

[d1ma4ek]

Ok. Your results are uploaded to me (I can view the results of the numerical model), but at the stage of grid formation and boundary conditions it gives an error, the gtawFoam solver itself gives an error referring to the transportProperties file, and for all examples. Unfortunately, only you can help, the variables must be specified there.

In your example in the thesis branch in the source code, you influence the velocity field by using the variable - lorentz*lorenz Units, which is found from the electromagnetic equation in the createEMFields file. It turns out that you took this force into account earlier?

I found a way to affect the surface with arc pressure. And I could add this term of the equation to your example. But so far I can't figure out how to launch your cases. Thank you.

[WillYeadon]

Every case should have a transportProperties file in it with the relevant variables? What does the error say specifically can you copy the text? In principle if something isn't defined you can just add it in with a value of 1 in transportProperties file and then add in units if required so cp2 [0 2 -2 -1 0 0 0] 381.5; or similar.

Huh yeah it does appear that lorentz is there along with EMEqn solving it. It was initially planned to be a part of the solver but I'd imagine those values are set to 0 at some point as I don't believe it to be a part of any of the simulations. If you can screenshot or copy/paste the error that is being outputted when you try to run gtawfoam.C I may be able to identify the issue.

[d1ma4ek]

Okay, for the first case, I get From the virtual Foam::autoPtr function Foam::FileOperations::uncollatedFileOperation::ReadStream(Foam::regIOobject&, const Foam::fileName&, const Foam::word&, bool) constant in the global/FileOperations/uncollatedFileOperation/file, there is an operation with an unassembled file.C in line 519.

for the chpt4-aluminum-Marg-dsdT-neg case when initializing boundary conditions

Foaming warning : From the void Foam::dlOpen(const Foam::fileName&, bool) function in the POSIX file.C in line 1234 dlopen error : libdynamicFvMeshUser.so : the shared object file cannot be opened: there is no such file or directory --> Warning about FOAM : From the bool function Foam::dlLibraryTable::open(const Foam::fileName&, bool) in the db/dynamicLibrary/dlLibraryTable/Library table file.C in line 105 failed to upload "libdynamicFvMeshUser.so " --> FOAM Warning : From the void Foam::dlOpen function(const Foam::fileName&, bool) in the POSIX file.C in line 1234 dlopen error : libsimpleSwakFunctionObjects.so : the shared object file cannot be opened: there is no such file or directory --> FOAM Warning : From the function bool Foam::dlLibraryTable::open(const Foam::fileName&, bool) in the db/dynamicLibrary/dlLibraryTable/Library table file.C in line 105 failed to upload "libsimpleSwakFunctionObjects.so " --> FOAM Warning : From the void Foam::dlOpen function(const Foam::fileName&, bool) in the POSIX file.C in line 1234 dlopen error : libswakFunctionObjects.so : the shared object file cannot be opened: there is no such file or directory --> Foaming warning : From the function bool Foam::dlLibraryTable::open(constant Foam::fileName&, bool) in the db/dynamicLibrary/dlLibraryTable/Library table file.C in line 105 failed to upload "libswakFunctionObjects.so " --> FOAM Warning : From the void Foam::dlOpen function(const Foam::fileName&, bool) in the POSIX file.C in line 1234 dlopen error : libgroovyBC.so : the shared object file cannot be opened: there is no such file or directory --> Warning about FOAM : From the bool function Foam::dlLibraryTable::open(const Foam::fileName&, bool) in the db/dynamicLibrary/dlLibraryTable/Library table file.C in line 105 failed to upload "libgroovyBC.so "

[d1ma4ek]

About the electromagnetic force. I think it should be taken into account, especially in welding examples with high current values from 200 A. I can give you a link if you need it.

[WillYeadon]

Do you have the swiss army knife (swak4foam) and groovybc libraries installed? That is what the error is, the first thing to try is in the controlDict file remove the offending libs:

libs ( "libdynamicFvMeshUser.so" "libOpenFOAM.so" "libsimpleSwakFunctionObjects.so" "libswakFunctionObjects.so" "libgroovyBC.so" );

If it requires swak, dynamicFvMesh and groovybc try installing them thou I don't believe it does.

For the 200 A cases I think you're correct, I could get away with it looking at vs small amps on thin walled tubes but for 200 A Lorentz will be significant along with the arc pressure. As I said, by the looks of things there is some sort of implementation I started but dropped due to wanting to get something completed for the thesis. To be honest this whole repo could do with an update, it sounds like you've already found beamWeldFoam which did a great job in my view. What specifically are you looking at? I assume this is some sort of academic/industrial project?

[d1ma4ek]

You're right, I probably won't be able to deal with this alone. I am studying PAW plasma arc welding. This is not a commercial project, I do all the research at my own expense. While I'm studying for a master's degree.

Obviously, with PAW, the heat source cannot be considered as a surface one, as there is a complex hydrodynamics in this process.

Indeed, by studying beamWeldFoam, I added pressure to the surface. However, there is an irresistible force of surface tension. In this beamWeldFoam project, if you imagine that the workpiece is on weight, then the welding bath does not go down. I have tried hundreds of options for boundary conditions and phase parameters. However, the only reason is the surface tension gradient. The exclusion of this force gives positive results. But I cannot unreasonably decrease or increase this power. For aluminum, I use -0.123e-3 H/m*K. What do you say about this?

Analyzing the source codes and equations, including in your dissertation, this force is calculated in the same way. I found 4 source codes of different projects. And everywhere it is written in this way: 1:dsigmadT(fvc::grad(T) - fvc::reconstruct(snv)(fvc::reconstruct(snv) & fvc::grad(T)))mag(fvc::grad(alpha2))(2*mixture.rho()/ (rho1 + rho2))

2:dsigmadT(gradT-nHatM(nHatM & gradT))*mag(gradAlpha)

3:dsigmadT2 (fvc::grad(T) - nHat (nHat & fvc::grad(T))) mag(fvc::grad(alpha1)) alpha2 * factor1

In any of these cases, the equation takes the form ∂σ/∂T (∇T − n(n · ∇T )) ∇α2 · ρ2(T )/ ρ2

But for the lower surface, it is obvious that something is wrong and this force is too great, and it does not allow the liquid metal to descend.

Therefore, I wrote to you when I saw that there is a Lorentz force in the original equation, perhaps it will help solve this problem.

I am ready to perform the necessary experiment and show the modeling technique. If you would help me, it would allow you and me to continue working with more complex projects. For example, vertical modeling.Keyhole modeling

I will try to supplement the missing libraries if possible.

[d1ma4ek]

Another question is, how did you transfer the power of the 1700 W heat source to the plane? After all, the conditions of heat propagation are changing. Sorry for asking such a stupid question.

[WillYeadon]

I used a volumetric heat source of the Goldak variety where cells were selected from a elliptical geometry and then temperature source terms were added, there are details in section 4.4.5.4 starting on page 61 then again in section 5.5 on page 99 in the thesis linked above. I found the paper that I originally based the heat source off "A simplified elliptic paraboloid heat source model for autogenous GTAW process" to be hard to replicate and instead I needed additional computational constants (e.g. no physics basis!?) that varied with the setup. In fact, one of my main results in chapter 5 was that many papers that I tried to replicate had few details about computational constants which it turned out are actually critical to the results so you can't just pick them arbitrarily.

If you don't want to use a volumetric heat source you will definitely need to work out the EM field as joule heating is a key energy transfer mechanism, I don't have experience in this so can't advise here. However, I would recommend you consider using a volumetric heat source initially as it will be easier and you can then compare it to a more advanced heat transfer model. If you create a long and thin ellipsoid it may look similar to PAW heat input; this simple model will give you something to compare against and you should be able to use the heatSourceClass implementation in this repo.

The difficulty in finding boundary conditions / "correct" thermophysical properties was a big issue for me. If the -0.123e-3 H/m*K value isn't working for you I'd recommend you try the same tactic as I did where you introduce a computational constant but benchmark that against other results. As I said above, I found replicating published results near impossible without computational constants and authors were often sparing in the details on their computational constants which isn't acceptable as they are critical and it sounds like you're finding the same thing if you "cannot unreasonably decrease or increase this power" with any physics justification.

The Marangoni implementation that I used was on Page 34 (44 of pdf) of "Marangoni driven free surface flows in liquid weld pools" by Zaki Saldi. That document is a highly cited thesis dedicated to Marangoni so I believe many people also opted to use that implementation. If that force / surface tension is too large on the bottom edge of a full penetration weld then I'd recommend defining a volScalarField in createFields like alpha_marangoni that is 1.0 everywhere that you can multiple that Saldi implementation line by. Then when you're running an actual case you can use setFields to set alpha_marangoni = 0 in the bottom half of your case geometry so that only the top bit would be affected.

Okay, I'm happy to answer any questions that you have. I've not really developed this any further since graduating so I'm not as familiar with the topic as I once was. Have you tried contacting the beamWeldFoam authors? Both @tomflint22 https://github.com/tomflint22 and @philipcardiff https://github.com/philipcardiff look active on github and are probably more up to date with things than me.

[d1ma4ek]

Thank you. Regarding constants, do you mean thermal efficiency? That's right, thermal efficiency can vary over a wide range. The axial heat flow and its distribution over the surface are changing.

In a planar problem, the Marangoni force on the lower surface works correctly. So the force calculated by this formula works only in one direction X ?

So I also need to go to the planar task, but I haven't figured out how to select cells yet.

[tomflint22]

Hey, sorry can you catch me up. What are you talking about?

[d1ma4ek]

Hey, sorry can you catch me up. What are you talking about?

Hi, Tom. I'm sorry I didn't want to bother you. We talked about this issue https://github.com/tomflint22/beamWeldFoam/pull/6 On your recommendation, I did my best, and found that the back surface rises due to the gradient of surface tension.

You also said that electromagnetic force can affect this. Then I found this source code in which they tried to take into account the electromagnetic force. But we came to the conclusion that this will not affect the problem found, rather, on the contrary, it will only make it worse.

Tom, I'm going to continue the branch, our branch, and present my results with arc pressure.

[tomflint22]

OK, I just commented on your posts. The Marangoni force is definitely implemented correctly. It's probably that the temperature boundary condition isn't representative of your experiment. You could try moving further away from the boundary

[tomflint22]

Let me know how you get on. I'm happy to help

[WillYeadon]

Hi Both, I'm going to close this as an issue now as we're moving slightly off topic here and it sounds like there is another discussion going on elsewise.

d1ma4ek, for the computational constants I mean terms with no physics basis such as the 'Darcy' phase change constant often set at 10^6 initially proposed in "A fixed grid numerical modelling methodology for convection-diffusion mushy region phase-change problems". Thermal efficiency clearly has a physics basis so I'd consider this a parameter of the simulation. The Maragoni implementation will work in all directions, it just considers the surface whether that surface is in the x-y plane of the z-y, x-z plane etc... should not matter. Gravity is likely to be a far larger reason behind any sag compared to Maragoni.

I hope that this discussion has helped you make some progress, please feel free to open another issue if you have more questions.