Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nonlinear heater initial additions #144

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

hammy4815
Copy link

@hammy4815 hammy4815 commented Mar 31, 2024

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.

Copy link
Owner

@HelgeGehring HelgeGehring left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment on lines +332 to +341
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]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 🤔 )

Comment on lines +335 to +336
ϵ_conductivities = u -> (ϵ_conductivities_base ∘ τ) + (ϵ_conductivities_linear ∘ τ) * u
Gridap.gradient(::typeof(ϵ_conductivities), du) = (ϵ_conductivities_linear ∘ τ) * du
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here it seems perfect to just throw in the solution of the linear solve, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants