Nonlinear heater initial additions #144
Conversation
There was a problem hiding this comment.
Looks great!
From the point of the interface, I'd mostly say we should try to make it as convenient as possible to turn off/on the nonlinear effects.
Also to have a definition which we can just evaluate at a certain temperature to calculate the linear effects seems to me quite desirable as we don't need to define anything twice.
Thus, I'd rather always use the nonlinear definition and then just evaluate it at a certain temperature for the linear solve.
(Which also allows to see the effect of the ambient temperature on the dynamics or to just try to guess the temperature as good as possible to just lower the differences to the nonlinear solve)
For the performance, we should probably use the linear solve as a starting point and then apply the nonlinear solve starting from there?
I'm also wondering how much we could win if we wisely choose the starting vector 🤔 I mean we know it heats up where the power is dissipated... And then the environment of that location get's warm....
Just wondering, no idea if it saves in the end a reasonable amount of runtime.
What do you think?
For the transient: I'm wondering how much we could win if we play with the convergence criteria - we probably don't need to converge to machine precision for each step 🤔
I'd expect that the relevant dynamics is already covered in only a few iterations.
If we there only converge down to an error of a few percent, that should speed up the calculation a lot and only introduce an error which is probably smaller than what we would get because of a not fine enough mesh?
| T0, ϵ_conductivities = if nonlinear_flag | ||
| ϵ_conductivities_base(tag) = thermal_conductivities_base[tag] | ||
| ϵ_conductivities_linear(tag) = thermal_conductivities_linear[tag] | ||
| ϵ_conductivities = u -> (ϵ_conductivities_base ∘ τ) + (ϵ_conductivities_linear ∘ τ) * u | ||
| Gridap.gradient(::typeof(ϵ_conductivities), du) = (ϵ_conductivities_linear ∘ τ) * du | ||
|
|
||
| T0 = calculate_temperature(ϵ_conductivities, power_density(p0), boundary_temperatures; solver=NLSolver(method=:newton)) | ||
| T0, ϵ_conductivities | ||
| else | ||
| ϵ_conductivities = tag -> thermal_conductivities_base[tag] |
There was a problem hiding this comment.
Would it make sense to just always make it a function?
Even through that function would be able to deliver more information, we don't need to use the additional information in the end.
What do you think?
I somehow would like to have a definition of the model which is as comprehensive as possible, but then we can select if we want to use the nonlinear information.
We'd then just tell calculate_temperature at what temperature to get the thermal conductivities/... (or call it ourselves before calling that function)
(This would for example be useful if we would simulate the same structure without nonlinear effects at different temperatures 🤔 )
| ϵ_conductivities = u -> (ϵ_conductivities_base ∘ τ) + (ϵ_conductivities_linear ∘ τ) * u | ||
| Gridap.gradient(::typeof(ϵ_conductivities), du) = (ϵ_conductivities_linear ∘ τ) * du |
There was a problem hiding this comment.
This one confuses me a bit on the first glance - should we maybe call it T (like temperature) instead of u to make clear what's the variable?
| ϵ_conductivities = u -> (ϵ_conductivities_base ∘ τ) + (ϵ_conductivities_linear ∘ τ) * u | ||
| Gridap.gradient(::typeof(ϵ_conductivities), du) = (ϵ_conductivities_linear ∘ τ) * du | ||
|
|
||
| T0 = calculate_temperature(ϵ_conductivities, power_density(p0), boundary_temperatures; solver=NLSolver(method=:newton)) |
There was a problem hiding this comment.
Would it make sense to do first a linear solve and use that as a starting point for the nonlinear solve?
I'd expect rather small differences in the nonlinear solve from the linear solve 🤔
But probably it would only matter if the first step is done using a direct solver?
| )*dΩ | ||
|
|
||
| op = FEOperator(res, jac, U, V) | ||
| x = rand(Float64,num_free_dofs(U)) |
There was a problem hiding this comment.
Here it seems perfect to just throw in the solution of the linear solve, right?
This (incomplete) PR contains the initial changes for the nonlinear heater by introducing a temperature dependent thermal conductivity.
Currently, the nonlinear transient takes way too long. So this needs to be fixed before we can pull. This is mostly a proof of concept for the setup.
I added two new methods. One for calculate_temperature_transient and one for calculate_temperature. These include replacing the thermal_conducivity from a CellField to a function defined by the user and also changing the type of solver to NonlinearSolver.
The user in addition to defining the ϵ_conductivities function (as a function of temperature), needs to define its gradient to be used with the nonlinear solver's jacobian.
If we want to include more information such as phase shift information this is still a ToDo.
Additionally, this PR also contains overlap of the visualization from the other PR.
At this stage there isn't a need to check workflows, I'm mostly curious on thoughts regarding the implementation first.