Why are the memory numbers reported different in v11 and v10 profiles

First review two comparable adaptive pass profiles in v10 and v11

V10
Adaptive Pass N                                    Frequency: 2.45 GHz                                         
  mesh3d_adapt_FT     
00:00:11   00:00:10  61 M    49690 tetrahedra                           
  p1_solve            

00:00:01   00:00:00  10.2 M  92 triangles                                                  
  adapt_part1         

00:00:23   00:00:23  155 M   49690 tetrahedra                  
  Solver MCS2         

00:01:34   00:02:33  1.36 G  308322 matrix, 165MB disk   
  adapt_part2         

00:00:06   00:00:06  140 M   49690 tetrahedra                        
                                                   Adaptive Passes converged
V11
Adaptive Pass N                                    Frequency: 2.45  GHz
  g3dm_vadapt         
00:00:12   00:00:12  83.8 M  44820 tetrahedra
Simulation Setup     

00:00:05   00:00:05  61.8 M  Disk = 0 Kbytes
Matrix Assembly      
00:00:10   00:00:09  208 M   Disk = 0 Kbytes, 43994 tetrahedra , p1: 106 triangles
Solver MCS2           
00:01:30   00:02:44  1.43 G  Disk = 0 Kbytes, matrix size 278139 , matrix bandwidth  22.0
Field Recovery        
00:00:04   00:00:04  1.43 G  Disk = 3118 Kbytes, 1 excitations
                                                   Adaptive Passes converged

Some questions that may arise are…
1)
In v10, for more tetrahedra there is less memory used than in v11 (but v11 solved faster real time but slower CPU time). These results are difficult to reconcile. Is there an explanation for this? Is this related to how things are reported or related to the new matrix generation/solving in v11?
2)
For this on-core solution (8GB RAM on solution machine) in v10, 165 MB is written to disk. What exactly is written to disk in v10; fields, mesh? Is there a corresponding value for v11?
3)
Why is the memory used for the solver and field recovery identical in v11?


HFSS11 is structured much differently from HFSS10. In HFSS10, adapt_part1, solver and adapt_part2 are standalone executables. They communicate through files and, of course, need disk usage. The RAM reported is peak memory for each executable. In HFSS11, Simulation Setup, Matrix Assembly, Solver and Field Recovery are library calls. They communicated through memory, which is typically much faster than file I/O. No disk usage is required until necessary, such as in the case of off-core direct solver and a large number of right hand sides. The RAM reported in profile is peak memory for the entire solution process. That's why you get the same RAM for Solver and Field Recovery since the peak RAM happens in Solver. Field Recovery actually uses far less RAM.

    In HFSS11, while matrix solver is being invoked, other data like mesh, material and boundary still sit in memory. In other words, the RAM reported for Solver in HFSS11 not only includes memory for matrix but also for mesh and others. In HFSS10, only the matrix is in memory while solver is being invoked. The RAM reported in profile is for matrix only.
    The CPU and real time difference is mainly caused by VC++ compiler and Intel Fortran library (low level math libraries). As you can imagine, while HFSS has different versions from time to time, so do the VC++ compiler and some low level system math libraries. They may cause differences in solver speed.