New Kernel terms in Diffusion equation

[sidharthsarmah]

Hi, I am trying to form an analogy between the heat and diffusion equation, can you please help me sort the additional terms involved?

Please note this is a coupled problem, where the diffusion depends on the stress and concentration gradient, please suggest solving it.

Heat Equation available in MOOSE:

[GiudGiud]

Hello

You should follow the application development tutorial, these terms are not very complicated you could code that up.
https://mooseframework.inl.gov/getting_started/examples_and_tutorials/tutorial01_app_development/index.html

Are these all regular field variables (eg 1 value per quadrature point) or are some of them vectors/tensors?

Guillaume

[hugary1995]

The stress gradient term need some attention. The rest terms are straightforward.

[sidharthsarmah]

Term 1: is it correct?

[sidharthsarmah]

Term 2: I have learn to us the time derivative, please let me know if this is the right way?how to implement this variables?

[GiudGiud]

Hello

please use triple back quotes to format the code pasted

The diffusion term looks good

The time derivative is not finished. You should use the coupleable interface to get the values of Ct in the coefficient in front of the derivatives. CoupledForce is an example of a kernel doing that.

You also need to add parameters for Ct and theta_l

otherwise I dont see an issue

Guillaume

[sidharthsarmah]

Second term: I have tried to implement the varied coefficient of the time derivative. Since, coupled variable concept in MOOSE is new to me, I have considered theta_t = 0.0005. But the coefficient function with the coupled variable (Ct = trap_conc) is showing an error, please help.

[GiudGiud]

Seems you are using material properties not the coupleable interface

  v = trap_conc
    d_function = 1 + (1-0.0005)*(trap_conc/lattice_conc)

this seems problematic.
The d_function is supposed to be the name of a material property but you are passing a parsed expression.
This parsed expression should be in a DerivativeParsedMaterial, which will define all the material properties then you can retrieve them in the kernel as you currently do

[sidharthsarmah]

Term 2: I tried implementing the coupled time derivative Kernel with function using DerivativeParsedMaterial, but there is an error, can you suggest how do I correct it, both C_t(trap_conc) and \theta-t are the coupled variable with the time derivative variable C_l(lattice_conc)?

[sidharthsarmah]

I think I am able to implement this coupled time derivative term, could you please check if it is correct?

But I have two coupled variables in this equation, C_T and \theta_T. In this, I have considered \theta_T as a constant = 0.0005, but I want to also make it a variable, can you help me what changes I need to make in the time derivative Kernel?

[hugary1995]

@sidharthsarmah The process you are going through is the so-called verification stage in code development. In FEM code, typically two methods are used in this process:

1. Patch test: You'll need to setup a problem that is as simple as possible in which the analytical solution is known, and the solution can be exactly matched by the basis function of your choice. For example, you can create a single-element cube, apply Dirichlet BC on one side, and apply Neumann BC on the opposite side. By applying your kernels one at a time, you can easily match the numerical solution (given by MOOSE) with the analytical solution.
2. Method of manufactured solution: This method is documented here https://mooseframework.inl.gov/python/mms.html. In essence, you will first manufacture an arbitrary, non-homogeneous solution, and then work your way back to derive the corresponding "body force" that would result in the manufactured solution. Even if the manufactured solution can't be exactly represented on the basis function of your choice, you should still see optimal order of convergence by looking at the appropriate error measure.

Let us know if you have specific questions regarding either method.

[sidharthsarmah]

@GiudGiud Hi, can you please help me with this one, its a part of my PhD work.
Is the time derivative kernel correct?
How do I couple a third variable (theta_T)?

[GiudGiud]

To couple in additional variables, use the coupleable interface still.
This is a call to coupledValue("name of parameter for that variable") in the constructor
There are lots of examples in the repo:
in a postprocessor:
https://github.com/idaholab/moose/blob/c42b80999f9a1a7aaa09c96484fc8a760f992359/framework/src/postprocessors/ElementVectorL2Error.C
in a kernel (it s all templated that s why the function names are "Generic" but just use the normal ones instead
https://github.com/idaholab/moose/blob/next/framework/src/kernels/CoupledForce.C
in a time derivative kernel (careful, this is dv/dt in the equation for variable u != v, not quite your case)
https://github.com/idaholab/moose/blob/next/framework/src/kernels/CoupledTimeDerivative.C

[sidharthsarmah]

Hi @GiudGiud, being a new MOOSE user, I am a bit confused now regarding how to implement this couple of time derivatives now.

I think some examples contain a time derivative which is not couple, some contain coupled but no time derivative, and some are coupled but do not include the time derivative variable in the coefficient expression, could you help me digest things a bit slowly?

Can I first show you the kernels that I have developed and you make a comment, thanks!

[sidharthsarmah]

*** ERROR ***
The following error occurred in the object "TimeStepper", of type "ConstantDT".

Solve failed and timestep already at or below dtmin, cannot continue!

@GiudGiud

1. I have rearranged the equation to a two variable terms(C_L -> lattice_conc, C_T -> trap_conc), can you please check if the Kernels are correct?

2. Also the error in convergence is due to the values that I have selected and has nothing to do with the kernels right?

[sidharthsarmah]

Hi @GiudGiud,

These are the .h and .C files for HTimeDerivative, can you tell me what changes are to be made to include the full Jacobian or refer to a problem, which I can seek to make those changes, thanks!

Because when I increase the number of elements, other than 1, the following error occurs:

*** ERROR ***
The following error occurred in the object "TimeStepper", of type "ConstantDT".

Solve failed and timestep already at or below dtmin, cannot continue!

[sidharthsarmah]

Ok @GiudGiud , I have removed these prop lines from DerivativeParsedMaterial as its already defined in GenericConstantaMaterial, it is correct? But now I ran into an another error:

*** ERROR ***
Invalid function
1 + (trap_conc/lattice_conc)*(1 - 1/(((NL+lattice_conc)/lattice_conc)exp(WB/(RT))+1))
lattice_conc,trap_conc
in ParsedMaterialHelper.
Syntax error: Unknown identifier

Also, if I include now these properties into args, I get this error:

*** ERROR ***
diff_time_function: Coupled variable 'NL' was not found

[GiudGiud]

oh my bad I didnt see you had set them as material proeprties.
material_property was fine then.

[sidharthsarmah]

Ok, thanks @GiudGiud , but still I get error when the mesh have more elements, please suggest, could you comment on the .h and .C files regarding the Jacobins above, is it due to that?

*** ERROR ***
The following error occurred in the object "TimeStepper", of type "ConstantDT".

Solve failed and timestep already at or below dtmin, cannot continue!

[GiudGiud]

what does the jacobian analyzer say about your Jacobian?
Can you please also attach (not paste) the full simulation log?

[GiudGiud]

and then the constants ([material_property_names = 'NL WB R T'])

I dont think they should be material properties.
There's a different argument for constants, constant_expressions and constant_names

[GiudGiud]

The gradient of a linear or an auxvariables can be retrieved exactly the same way using coupledGradient("variable_name")

Are sigma_h and eps_p auxvariables though? Can you determine with a simple operation from other quantities?

If not, then they should be nonlinear variables if they have their own equation to solve non-linearly

If so, will you need propagate derivatives of the nonlinear variables through these quantities to form the Jacobian?
If you need to, then they need to be material properties not auxiliary variables.

We do not have the manpower to implement other's kernels. We are available to fix bugs and to help with contributions to MOOSE and its modules in some capacity.

[sidharthsarmah]

Hi @GiudGiud ,

Thank you for your reply. I plan to develop the kernels myself, but will need your assistance.

Here is the sigma_h (https://mooseframework.inl.gov/source/utils/RankTwoScalarTools.html) and eps_p (https://mooseframework.inl.gov/source/auxkernels/MaterialRealAux.html) description as aux variable.

Can you suggest how do I implement aux variable in Kernels?

[GiudGiud]

the coupledXXX routines and adCoupledXXX routines let you use auxvariables in kernels
see this one for example. It also shows how to use material properties
https://github.com/idaholab/moose/blob/next/framework/src/kernels/MatCoupledForce.C

[GiudGiud]

there's more on making kernels in the tutorials

[sidharthsarmah]

2Hi @GiudGiud,

I plan to create the kernels step by step and would need your help in the same.

First I want to implement the hydrostatic term:

I am defining the parameters and the out here:

Is it right?

v means hydrostatic stress and u is the CL

[sidharthsarmah]

Hi @GiudGiud ,

I have tried to implement this equation in MOOSE (strain rate term not yet developed), could you please suggest why there is an issue with the convergence?

[GiudGiud]

Does it converge on a simpler system?

Can you attach the convergence history as well please

[sidharthsarmah]

Hi @GiudGiud

I tried for this simple problem and it seems there is an convergence issue:

Error:

97 Nonlinear |R| = 2.406784e+08
      0 Linear |R| = 2.406784e+08
      1 Linear |R| = 3.154084e+05
98 Nonlinear |R| = 2.406784e+08
      0 Linear |R| = 2.406784e+08
      1 Linear |R| = 3.154084e+05
99 Nonlinear |R| = 2.406784e+08
      0 Linear |R| = 2.406784e+08
      1 Linear |R| = 3.154084e+05
100 Nonlinear |R| = 2.406784e+08
Nonlinear solve did not converge due to DIVERGED_MAX_IT iterations 100
 Solve Did NOT Converge!
Aborting as solve did not converge


*** ERROR ***
The following error occurred in the object "TimeStepper", of type "ConstantDT".

Solve failed and timestep already at or below dtmin, cannot continue!

Stack frames: 11
0: 0   libmesh_opt.0.dylib                 0x0000000111cd5123 libMesh::print_trace(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) + 1091
1: 1   libmoose-opt.0.dylib                0x000000010f51fa27 moose::internal::mooseErrorRaw(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 823
2: 2   libmoose-opt.0.dylib                0x000000010f47ef6f callMooseErrorRaw(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, MooseApp*) + 111
3: 3   libmoose-opt.0.dylib                0x000000010e6fa25a void MooseObject::mooseError<char const (&) [70]>(char const (&) [70]) const + 346
4: 4   libmoose-opt.0.dylib                0x000000010ef2303b TimeStepper::computeFailedDT() + 75
5: 5   libmoose-opt.0.dylib                0x000000010ef323ed TimeStepper::computeStep() + 109
6: 6   libmoose-opt.0.dylib                0x000000010e857354 Transient::execute() + 100
7: 7   libmoose-opt.0.dylib                0x000000010f4f0801 MooseApp::executeExecutioner() + 273
8: 8   libmoose-opt.0.dylib                0x000000010f4ebac9 MooseApp::run() + 1705
9: 9   tensor_mechanics-opt                0x000000010278fbaf main + 159
10: 10  dyld                                0x000000020283e310 start + 2432
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
[unset]: write_line error; fd=-1 buf=:cmd=abort exitcode=1
:
system msg for write_line failure : Bad file descriptor
(moose) sidharthsarmah@Sidharths-MacBook-Air tensor_mechanics % 

[GiudGiud]

A few things to try:

• switch to Newton instead of PJFNK
• use the jacobian analyzer to make sure your jacobian is correct
• add a strong preconditioner like LU
• check if the problem is singular using SVD

97 Nonlinear |R| = 2.406784e+08
      0 Linear |R| = 2.406784e+08
      1 Linear |R| = 3.154084e+05
98 Nonlinear |R| = 2.406784e+08
      0 Linear |R| = 2.406784e+08
      1 Linear |R| = 3.154084e+05

this is odd. It should not snap out of the linear solve if it s not converged

[sidharthsarmah]

Hi @GiudGiud,

I change it to NEWTON and checked the Jacobian.

Please note carefully, I am confused about somethings:

1. Since kernels in MOOSE identify each of the components in a weak form, how does it decides the sign of the components of the second term?
   In this, I have considered a negative sign as on the LHS the term has a negative sign, could you please explain how MOOSE decides it, or implicitly included in the source files?

2. By trail and error,
   2.1. I have excluded the BCs, and the solution converged, with (+)DL.

      1 Linear |R| = 1.099549e-08
 7 Nonlinear |R| = 1.363439e+02
      0 Linear |R| = 1.363439e+02
      1 Linear |R| = 1.820089e-12
 8 Nonlinear |R| = 3.593073e-02
 Solve Converged!
  Finished Solving                                                                       [ 39.87 s] [  -54 MB]

Outlier Variable Residual Norms:
  conc_lattice: 3.593073e-02

2.2. Then I scaled the BCs to a lower value by dividing by 1000, and then it converges.

But when I use the actual BCs, it is converging in some time step, while not in others.
Do you think it has something to do with the BCs or the stress-strain law in the plastic region which is not defined correctly, because of which the displacement in the BCs could not be processed in the plastic regions.

Could you suggest if it is the right way to do, or is there are functions materials to define the stress-strain relation?please suggest, thanks!

Nonlinear solve did not converge due to DIVERGED_DTOL iterations 9
 Solve Did NOT Converge!
  Finished Solving                                                                       [ 46.30 s] [    0 MB]
Aborting as solve did not converge

Time Step 16, time = 0.2125, dt = 0.0125
 0 Nonlinear |R| = 2.111891e+13
      0 Linear |R| = 2.111891e+13
      1 Linear |R| = 2.838776e-02
 1 Nonlinear |R| = 8.246287e+06
      0 Linear |R| = 8.246287e+06
      1 Linear |R| = 1.069833e-03
 2 Nonlinear |R| = 1.891091e+08
      0 Linear |R| = 1.891091e+08
      1 Linear |R| = 8.136889e-04
 3 Nonlinear |R| = 1.163888e+10
      0 Linear |R| = 1.163888e+10
      1 Linear |R| = 3.348810e-04
 4 Nonlinear |R| = 4.651572e+09
      0 Linear |R| = 4.651572e+09
      1 Linear |R| = 4.136528e-05
 5 Nonlinear |R| = 2.053012e+09
      0 Linear |R| = 2.053012e+09
      1 Linear |R| = 5.502774e-06
 6 Nonlinear |R| = 2.264905e+07
      0 Linear |R| = 2.264905e+07
      1 Linear |R| = 2.435616e-07
 7 Nonlinear |R| = 2.304235e+04
      0 Linear |R| = 2.304235e+04
      1 Linear |R| = 1.003742e-09
 8 Nonlinear |R| = 6.924306e-01
 Solve Converged!
  Finished Solving                                                                       [ 40.81 s] [    1 MB]

Outlier Variable Residual Norms:
  conc_lattice: 6.924306e-01

Values in stress_data.csv (stress vs plastic strain)
<img width="169" alt="image" src="https://user-images.githubusercontent.com/110927986/211465384-46ea6dfd-a19b-4080-a3dc-e23bb543f0ba.png">


Define stress in both elastic and plastic region:

[milljm]

Looks like we need to install python and packaging:

mamba activate moose
mamba install python=3.10 packaging
export METHOD=oprof METHODS=oprof MOOSE_JOBS=4
cd ~/MOOSE/projects/moose
git clean -xfd   # cleans out the failed build
cd modules/tensor_mechanics
make -j 4

[milljm]

Once or if this completes, you should be in a good spot to start profiling (I am heading home for the day).

[sidharthsarmah]

Thanks @milljm , Jason Miller, so much.

With the app being done, do I need to start building the profiling from start.

Step 1:

cd [your-moose-app-repository]
make

Step 2.

MOOSE_PROFILE_BASE=run1_ mpiexec -n 32 ./your-app_oprof -i input_file.i

[sidharthsarmah]

Thanks, I will indeed, work a bit more on it, thanks a lot for the day, have a great evening.

[milljm]

Yeah, when I say "start profiling" I mean you should be able to perform all the profiling bits present on the Profiling instruction page. Including what you posted as steps 1 and 2!

Cheers!

[sidharthsarmah]

Great, some few doubts:

1. No opt file for app obtained after running make -j4.

mamba activate moose
mamba install python=3.10 packaging
export METHOD=oprof METHODS=oprof MOOSE_JOBS=4
cd ~/MOOSE/projects/moose
git clean -xfd   # cleans out the failed build
cd modules/tensor_mechanics
make -j 4

2. I encountered an error while running profiling:

cd $HOME
git clone git@github.com:gperftools/gperftools.git
cd gperftools
./autogen.sh
./configure --prefix=$PWD/installed --enable-frame-pointers
make -j$MOOSE_JOBS
make install

/Users/sidharthsarmah/mambaforge3/envs/moose/bin/arm64-apple-darwin20.0.0-ranlib: archive member: .libs/libtcmalloc_internal.a(libtcmalloc_internal_la-memfs_malloc.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)
libtool: link: arm64-apple-darwin20.0.0-ranlib .libs/libtcmalloc_internal.a
arm64-apple-darwin20.0.0-ranlib: archive member: .libs/libtcmalloc_internal.a(libtcmalloc_internal_la-memfs_malloc.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)
arm64-apple-darwin20.0.0-ranlib: for architecture: x86_64 file: .libs/libtcmalloc_internal.a(libtcmalloc_internal_la-memfs_malloc.o) has no symbols
warning: arm64-apple-darwin20.0.0-ranlib: archive library: .libs/libtcmalloc_internal.a for architecture: x86_64 the table of contents is empty (no object file members in the library define global symbols)
make: *** [Makefile:3881: libtcmalloc_internal.la] Error 1
(moose) sidharthsarmah@Sidharths-MacBook-Air gperftools % 

[sidharthsarmah]

I found errors now while running make -j 4:

(moose) sidharthsarmah@Sidharths-MacBook-Air tensor_mechanics % make -j4
Linking Library /Users/sidharthsarmah/MOOSE/projects/moose/framework/contrib/pcre/libpcre-opt.la...
Linking Library /Users/sidharthsarmah/MOOSE/projects/moose/framework/contrib/hit/libhit-opt.la...
Linking Executable /Users/sidharthsarmah/MOOSE/projects/moose/framework/contrib/exodiff/exodiff...
Creating Unity /Users/sidharthsarmah/MOOSE/projects/moose/modules/tensor_mechanics/build/unity_src/kernels_Unity.C
Linking Library /Users/sidharthsarmah/MOOSE/projects/moose/modules/tensor_mechanics/test/lib/libtensor_mechanics_test-opt.la...
ld: library not found for -lmesh_opt
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [/Users/sidharthsarmah/MOOSE/projects/moose/framework/moose.mk:362: /Users/sidharthsarmah/MOOSE/projects/moose/framework/contrib/hit/libhit-opt.la] Error 1
make: *** Waiting for unfinished jobs....
ld: library not found for -lmesh_opt
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [/Users/sidharthsarmah/MOOSE/projects/moose/framework/moose.mk:350: /Users/sidharthsarmah/MOOSE/projects/moose/framework/contrib/pcre/libpcre-opt.la] Error 1
ld: library not found for -lmesh_opt
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [/Users/sidharthsarmah/MOOSE/projects/moose/framework/moose.mk:413: /Users/sidharthsarmah/MOOSE/projects/moose/framework/contrib/exodiff/exodiff] Error 1
(moose) sidharthsarmah@Sidharths-MacBook-Air tensor_mechanics % 

[GiudGiud]

METHOD=oprof make -j 4

Of course it does not compile in opt mode (the default mode), we're trying to set you up for profiling.

You dont need to recompile anyway! You have the tensor_mechanics-oprof executable right there.

[milljm]

• Step 1:
  • METHOD= dictates the suffix of your app. So if METHOD=opt, you will get tensor_mechanics-opt. But in order to profile something, you need METHOD=oprof. So what you have available right now is the desired binary.
• Step 2:
  • You don't need to install gperftools. You did that already when you installed mamba install moose-pprof.

You only need now start profiling your code. Go here: Profiling MOOSE Code and skip down to "CPU Profiling"

[GiudGiud]

Are both simulations well converged?
The 30 units, does that come in the pull_x and y functions?

[sidharthsarmah]

This is for KI=3

 Solve Converged!
  Finished Solving                                                                       [ 12.51 s] [    0 MB]

Outlier Variable Residual Norms:
  conc_lattice: 2.375179e+00

[GiudGiud]

conc_lattice: 2.375179e+00
this seems too high and potentially unconverged
Could you please paste the Executioner block

[sidharthsarmah]

I am reposting it:
here is for
For KI=3

 Solve Converged!
  Finished Solving                                                                       [ 12.51 s] [    0 MB]

Outlier Variable Residual Norms:
  conc_lattice: 2.375179e+00

**************EXECUTIONER**************

[Executioner]

  type = Transient

  solve_type = 'NEWTON'

  petsc_options_iname = '-pc_type'
  petsc_options_value = 'lu'

  line_search = 'none'
  automatic_scaling = true

  start_time = 0.0
  dtmin = 0.01
  dtmax = 0.1
  end_time = 1.0

  [TimeStepper]
    type = IterationAdaptiveDT
    dt = 0.0001
  []

[]

For KI=30;

 Solve Converged!
  Finished Solving                                                                       [ 12.92 s] [   -2 MB]

Outlier Variable Residual Norms:
  conc_lattice: 2.835050e-02

#**************EXECUTIONER**************

[Executioner]

  type = Transient

  solve_type = 'NEWTON'

  petsc_options_iname = '-pc_type'
  petsc_options_value = 'lu'

  line_search = 'none'
  automatic_scaling = true

  start_time = 0.0
  dtmin = 0.001
  dtmax = 0.01
  end_time = 1.0

  [TimeStepper]
    type = IterationAdaptiveDT
    dt = 0.0001
  []

[]

[GiudGiud]

let's set nl_rel_tol to 1e-12

[sidharthsarmah]

Hi @GiudGiud ,

Can you explain this doubt?

I am going over this tutorial (https://mooseframework.inl.gov/modules/heat_conduction/tutorials/introduction/therm_step03.html) where they solve this heat conduction equation:

Writing things on one side I obtain this:

How is the negative sign considered while writing the kernel? Why does it not taken into account?

Which of these two kernels (MatDiffusion or HeatConductionTimeDerivative have the (-)ve sign by default?

[Kernels]
  [heat_conduction]
    type = MatDiffusion
    variable = T
  []
  [time_derivative]
    type = HeatConductionTimeDerivative
    variable = T
  []
[]

[GiudGiud]

You ll need to take extra care to get monotonicity with finite element
You should first try to refine the mesh

[sidharthsarmah]

Actually that mesh is something I used for ABAQUS, do you think the discrepancy in the results, could be because of this?

[GiudGiud]

If you're trying to compare both you should probably use the same mesh.

[sidharthsarmah]

I am using the same mesh but results differ for higher loads, and I think its because of that reason, can you suggest something?

[GiudGiud]

You could investigate the issue by refining the mesh in both software

Overall I think taking it by step by step to identify what is different is the right approach

[sidharthsarmah]

Hi @GiudGiud , thanks.

Can you tell me how to apply a conditional BC.

Say I want to load a boundary with a load, force_y = 10*t for time 1 sec, and then keep it constant at 10 N, but continue the analysis for total 60 sec for only diffusion to take place, please suggest.

[GiudGiud]

you can try specifying a different time integration scheme, with scheme = BDF2 in the executioner for example

[GiudGiud]

Looks fine to me.

The range in temperature seems excessive. Are you really looking below -200K

[sidharthsarmah]

Hi @GiudGiud, I noticed that, It was in Celsius, I changed it to K, thanks as always.

[sidharthsarmah]

Hi @GiudGiud , this is something confusing to me. I tried converging using different time set and also using scheme = bdf2, but every time, the avg values seemed different, please assist:

#**************EXECUTIONER**************

[Executioner]

  type = Transient
  scheme = bdf2
  solve_type = 'NEWTON'
  line_search = none

  petsc_options_iname = '-pc_type'
  petsc_options_value = 'lu'

  automatic_scaling = true
  l_tol = 1e-10
  nl_rel_tol = 1e-10
  nl_abs_tol = 1e-10
  nl_max_its = 10
  start_time = 0.0
  end_time = 87120
  dtmax = 1000

  [./TimeStepper]
    type = FunctionDT
    function = dts
    min_dt = 10
  [../]

[]

#***********POSTPROCESSOR*************

[Postprocessors]
  [./Cavg]
    type = ElementAverageValue
    variable = cL
    execute_on = 'INITIAL TIMESTEP_END'
  [../]

  [./Tavg]
    type = ElementAverageValue
    variable = T
    execute_on = 'INITIAL TIMESTEP_END'
  [../]
[]

[GiudGiud]

weird. All equations have time derivatives right?
If you plot
Cavg_end as a function of the time step (with the same end_time)
(outside of moose, in a python script for example)

do you see it converge?