QuazarTech / DG_Maxwell

Solution of Maxwell equations using Discontinuous Galerkin method.
GNU General Public License v3.0
9 stars 5 forks source link

Increase iteration rate for more number of time steps. #14

Open Balavarun5 opened 7 years ago

Balavarun5 commented 7 years ago

Commit hash : e0d09e2b57beaf5aff2e825812aa598e8e7d19ad

Description

Ref:- Issue #5 The existing code (run by typing python3 main.py ) in the terminal has serious setbacks while running for larger times. The speed reduces to as low as 30 iterations/second (On Inspiron-3542).

Motivation

A better solution is needed as this approach has serious limitations on the time for which the simulations can be done.

Possible Implementation

Creating a self contained code, The iterations/second was observed to be higher.

The file 1D_wave_equation_bug.py is a python file obtained from a self contained ipython notebook 1D_wave_equation_bug.ipynb. The wave equation evolves at a constant, much faster rate in the notebook.

Running the 1D_wave_equation_bug.py file in the commit hash mentioned above shows that the speed is independent of the size of the array (approx. - 300 iterations/second).

Probable cause of issue

Unknown

amanabt commented 7 years ago

Where will I find 1D_wave_equation_bug.py?

amanabt commented 7 years ago
Creating a self contained code which doesn't use global variables might help.

Why do you think that this will help?

Balavarun5 commented 7 years ago

The file 1D_wave_equation_bug.py can be found here - https://github.com/Balavarun5/DG_Maxwell/blob/analytic_surface_term_test/code/1D_wave_equation_bug.py

Note - This is a python file created using the ipynb. Edit - This version of the file evolves the 1D wave for 50 seconds for 8 LGL points and 10 elements

Balavarun5 commented 7 years ago

Creating a self contained code which doesn't use global variables might help.

I am trying to fit the result (The iteration rate being faster) to something that was done differently when I wrote the notebook. One major feature that was not common was the usage of global variables. I am not completely sure of the reason hence the statement

amanabt commented 7 years ago

It was already established in issue #5 that the speed was decreasing with increasing size of the arrayfire array which was storing the u. To resolve this we even implemented this version of the 1D wave equation solver which used hdf5 to stores u. I ran this on my computer and as far as I remember, I was getting a speed of about 500 iterations/sec and we were using a lot of global variables even in that program.

I, however, was trying to understand how the global variables might be slowing our time iteration speed and I encountered an article locals_and_globals which has explained the how the local and global variables are handled in Python 2.2. This FAQ on local and global variables in Python 3 also indicates that global variables have a lower precedence over local variables. According to the article locals_and_globals, Python handles the variables using dictionaries which they call a namespace. We are concerned with these two namespaces:

- local namespace: Keeps track of the local variables.
- global namespace: Keeps track of the global variables.

When Python encounters a variable during the execution of a program, it looks for that variable in the namespaces, precedence is given to the local namespace compared to the global namespace. Note that Python doesn't access any of the variables at this stage. In our case, as discussed in issue

5 , the size of the global variable u has a significant effect on the iteration speed of the program.

But, the time that Python takes to find the global variable should be independent of the size of the variable. So, even if you make u a local variable, we should get almost the same iteration speed. I veryfied my hypothesis by running the program with u as a global variable for which I got the iteration speed to be 326 iter/s. In another program, I defined u as a local variable, keeping the size of the variable same and I was passing it as an argument to all the functions which needed the gvar.u.variable. I ran this on GPU and I was getting the same speed of 326 iter/sec.

Balavarun5 commented 7 years ago

I stopped using Global variables in the code and the speed hasn't improved. This is in line with your hypothesis. The bottleneck is somewhere else.

amanabt commented 7 years ago

Then what was this statement about?

Creating a self contained code which doesn't use global variables might help.

and even self contained code is not going to help.

mchandra commented 7 years ago

Yes, please get rid of all global variables. Not a good practise at all.

amanabt commented 7 years ago

@mchandra I agree. But in our case having global variables or a self-contained code have nothing to do with the speed of the code.

Balavarun5 commented 7 years ago

@amanabt Please keep in mind that the Issue was raised when I was unsure of the reason behind the code being slow. That said, I will update the issue message. Secondly the code is faster when it's self contained. You can check it by running the .py file I had mentioned earlier. I tried removing global variables from the code which did not help, But they never were required in the first place. And as Mani says, It's not a good practice.

Balavarun5 commented 7 years ago

I would also like to point out that the speed (iterations/second) is largely independent of the size of the array which seems odd.