Hi Misha, Thank you for your reply. What suggestion do you mean ? I dont see any suggestion in Steven's mail. Sure I can calculate Q using longer intervals and it is exactly what I am doing now. It works for Q's below 10^5 or something but I am writing this software for calculating nanocavities that have Q around 10^7 or even 10^9. In such cases the line steepness is very low and the differences in values extremly small so to calculate Q well I have to have a bigger statistic which means either more steps ( I can not do that because as I stated in some other mail the simulation in meep diverges for me, there start to appear some strange small waves propagating from the point where the source was located or from PMLs and the energy goes to infinity) or I can have more energy values to perform function fitting on. So I am coming back to the point where I need energy for every step. Of course I understand when you say that the generality has higher priority. I perfectly agree. But I also think that finding the total energy is a pretty common and important task and it deserves its own optimized function.
Thomas Jefferson 2008/7/29 Mischa Megens <[EMAIL PROTECTED]>: > Hi Jefferson, > > I suppose you don't need the total energy at every time step to fit the Q? > If you only calculate the energy say every 10 timesteps, for sure the run > time penalty will be much less? > Don't you think Steven's suggestion makes sense? > > Best, > M > > > [EMAIL PROTECTED] wrote on 29-07-2008 05:06:49: > >> My application requires it because I am computing the Q factor based >> on depencance of total energy on time. >> I have been trying to do in with the meep::do_harminv and the methods >> explained on >> http://ab-initio.mit.edu/wiki/index.php/Meep_C-plus-plus_Tutorial >> but It simply does not work for me. I was trying with different >> positons of probes, different ranges a.s.o. but every time I am >> getting strange results, every time different Q's on >> every probe, sometimes negative ones too, with strange frequencies >> that should not appear there. But when I just keep track of total >> energy and then fit a function to it by myself I get good results for >> Q >> so it means the setup is ok and the calculation of Q from E works. The >> one from fields on specific points somehow does not. >> >> I think it would be anyways very useful to have a totaly separate >> specialized routine for calculating the total energy. Or even better >> would be if >> it was calculated automaticaly during every time step as a side >> product of FDTD calculation. This way it should not slow down the >> calculation more then few percent and if >> there was an option to turn it off or on in the fields class >> constructor it would be perfect. >> >> Thomas Jefferson >> >> 2008/7/29 Steven G. Johnson <[EMAIL PROTECTED]>: >> > On Jul 28, 2008, at 12:19 AM, Jefferson Thomas wrote: >> >> double ex = fields->field_energy_in_box(meep::Ex, >> >> volume.surroundings()); >> >> double ey = fields->field_energy_in_box(meep::Ey, >> >> volume.surroundings()); >> >> double ez = fields->field_energy_in_box(meep::Ez, >> >> volume.surroundings()); >> >> double hx = fields->field_energy_in_box(meep::Hx, >> >> volume.surroundings()); >> >> double hy = fields->field_energy_in_box(meep::Hy, >> >> volume.surroundings()); >> >> double hz = fields->field_energy_in_box(meep::Hz, >> >> volume.surroundings()); >> > >> > Note that this is only first-order accurate, because it combines the E >> > and H field energy from different times (because the H field is offset >> > in time from E). See also: >> > >> > http://ab-initio.mit.edu/wiki/index. >> php/Synchronizing_the_magnetic_and_electric_fields >> > >> > for how to synchronize the fields before computing the energy. >> > >> > The reason that this is still fairly slow is that the energy-in-box >> > routine is implemented using a very general field-integration function >> > that supports integration of arbitrary user-defined functions of >> > multiple field components over arbitrary volumes in the grid. This >> > generality comes at a price. (Although it could probably be optimized >> > much more. e.g. looking at the total_energy routine, I noticed that >> > it performs integrals of some field components even in cases when it >> > could easily figure out a priori that they are zero.) >> > >> > A specialized integration routine just for the field energy would >> > certainly be far faster. Especially for a routine just to compute the >> > total field energy over the entire grid. Especially if you want to >> > add specialized code to your timestepping routines to keep track of >> > this information as you update the fields. >> > >> > However, generality has been a much higher priority in Meep that >> > optimizing particular functions that are normally not performance >> > sensitive. e.g. I'm not sure what circumstance you are in that you >> > need to calculate the total field energy in the grid at every time >> > step, but it is pretty unusual in my experience; normally you need >> > such integrals only every several timesteps at most. Could you say >> > something about why your application requires this? >> > >> > Steven >> > >> > _______________________________________________ >> > meep-discuss mailing list >> > meep-discuss@ab-initio.mit.edu >> > http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss >> > >> >> _______________________________________________ >> meep-discuss mailing list >> meep-discuss@ab-initio.mit.edu >> http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss > _______________________________________________ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
