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

Python wrapper last updates #357

Merged
merged 57 commits into from
Jan 18, 2017
Merged

Python wrapper last updates #357

merged 57 commits into from
Jan 18, 2017

Conversation

tobadavid
Copy link
Contributor

This PR introduces the last updates for the Python wrapper :

  • Ability to run a SU2 computation that can interact with an external Python environment in order to exchange data (in both directions).

  • The code has been cleaned and comments were added.

  • The structure for an arbitrary MPI communicator (other than COMM_WORLD) to be passed to the Python wrapper is set but cannot be used at this time. COMM_WORLD is still used by default.

  • The Python wrapper is now compatible with Mac OS.

PR #356 has to be closed first. Then I will push a last commit after merging with the fixed develop.

…f wrong use of the --parallel option when using the Py wrapper.
@tobadavid
Copy link
Contributor Author

Hi Tim,

Yes it would be great to have it like this indeed. Maybe we can keep it for a future PR ?

@tobadavid
Copy link
Contributor Author

Thanks for merging Tim, but you did not solve correctly the conflict on parallel_regression.py. We do not test the external FSI coupling for now, so it has to be removed ;). Everything is up to date now.

@talbring
Copy link
Member

Yep thanks! Didn't saw that when I merged it! Travis should pass now.

@tobadavid
Copy link
Contributor Author

And Travis did pass. As for me, everything is ready now.

Copy link
Member

@talbring talbring left a comment

Choose a reason for hiding this comment

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

Just some additional comments.


}

unsigned long CDriver::GetNumberHaloVertices(unsigned short iMarker) {

unsigned long nHalovertices(0), iVertex, iPoint;
Copy link
Member

Choose a reason for hiding this comment

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

Also here.

@@ -2781,27 +2854,48 @@ unsigned short CDriver::GetMovingMarker() {

unsigned long CDriver::GetNumberVertices(unsigned short iMarker) {

unsigned long nFluidVertex;
unsigned long nVertices(0);
Copy link
Member

Choose a reason for hiding this comment

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

Although it is not wrong, but maybe use an assignment here, so that it is consistent with the rest of the code.


#ifdef HAVE_MPI
typedef MPI_Comm SU2_Comm;
#else
Copy link
Member

Choose a reason for hiding this comment

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

Then lets move at least these typedefs to the mpi structure for now.

@tobadavid
Copy link
Contributor Author

I made the changes. Waiting for Travis.

@@ -34,5 +34,9 @@

#include "codi.hpp"

#ifdef HAVE_MPI
Copy link
Member

Choose a reason for hiding this comment

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

You probably just forgot to remove these.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When you look at the file everything seems to be ok, isn't it ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh no, I see...let me change this !

Copy link
Member

@talbring talbring left a comment

Choose a reason for hiding this comment

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

Thanks David! 👍

Copy link
Member

@economon economon left a comment

Choose a reason for hiding this comment

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

Getting close, David!

Just a few typos and comments here in the review. I guess the biggest thing is finalizing the name for the wrapped module...

@@ -273,30 +271,204 @@ class CDriver {
*/
virtual void SetInitialMesh() { };

/*--- External communication layer ---*/

/*!
Copy link
Member

Choose a reason for hiding this comment

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

Thanks for commenting these..


unsigned short val_iZone = ZONE_0;
unsigned short FinestMesh = config_container[val_iZone]->GetFinestMesh();
su2double CMy, RefDensity, RefAreaCoeff, RefLengthCoeff, RefVel2(0.0), factor;
Copy link
Member

Choose a reason for hiding this comment

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

Check RefVel2 initialization


unsigned short val_iZone = ZONE_0;
unsigned short FinestMesh = config_container[val_iZone]->GetFinestMesh();
su2double CDrag(0.0);
Copy link
Member

Choose a reason for hiding this comment

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

CDrag initialization


unsigned short val_iZone = ZONE_0;
unsigned short FinestMesh = config_container[val_iZone]->GetFinestMesh();
su2double CLift(0.0);
Copy link
Member

Choose a reason for hiding this comment

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

CLift initialization

//if(geometry_container[ZONE_0][MESH_0]->node[iPoint]->GetDomain()) partFluidSurfaceLoads[iVertex][0] = GlobalIndex;
//else partFluidSurfaceLoads[iVertex][0] = -1.0;
if(geometry_container[ZONE_0][MESH_0]->node[iPoint]->GetDomain()) {
/*--- It necessary to distinguish the halo nodes from the others, since they introduice non physical forces. ---*/
Copy link
Member

Choose a reason for hiding this comment

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

typo in "introduce"

@@ -1,7 +1,7 @@
#!/usr/bin/env python

## \file test_pyWrapper.py
# \brief Python script to launch SU2_CFD through the Python Wrapper
## \file SU2_CFD.py
Copy link
Member

Choose a reason for hiding this comment

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

Thanks for switching the name!

SU2Driver = SU2Solver.CHBDriver(options.filename, options.nZone, options.nDim);
elif (options.nZone == 2) and (options.fsi):
SU2Driver = SU2Solver.CFSIDriver(options.filename, options.nZone, options.nDim);
if options.with_MPI == True:
Copy link
Member

Choose a reason for hiding this comment

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

This is a nice addition so that folks can run in serial through Python.


%feature("autodoc","1");

%module(docstring=
"'SU2Solver' module",
"'WrapSU2' module",
Copy link
Member

Choose a reason for hiding this comment

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

The best name choice is still unclear for me.. ideally it would just be SU2, but the old Python framework already uses this. Perhaps "pySU2" instead? Any suggestions?

@tobadavid
Copy link
Contributor Author

Thanks Tom !

I made the changes (typo and initializations).

I would not choose just "SU2" for the Py wrapper name, since there already is a SU2 python folder. By the way this also contains some python driving functions and this might be confusing. The true python wrapper is what you get when you directly interface C++ functionalities with python through SWIG.

The previous name of the wrapper was SU2Solver but once again I would avoid it since the true goal of the wrapper is to interface functionalities that could be much deeper than just the solver level. The python wrapper is not just a solver.

So to avoid confusion I chose the name WrapSU2. pySU2 would do the job too and this is consistent with the pySU2 folder (used to compile the wrapper). SU2Wrapper ? PyWrapSU2 ? Just keep in mind that "SU2" should be part of the name, imagine you have to import two wrapped modules (from different codes) in the same python script I would prefer having :


import pySU2 # wrapper of SU2
import pyOtherCode # wrapper of another code


than having :


import pyWrap # wrapper of SU2 but this is unclear
import theWrapper # wrapper of an other code but this is unclear


@talbring
Copy link
Member

In my opinion pySU2 would be a good name.

@tobadavid
Copy link
Contributor Author

I agree, let's wait for other suggestions if any.

@economon
Copy link
Member

I'm fine with pySU2 as well, but yes, let's hear any other ideas.

@arubino
Copy link
Member

arubino commented Jan 14, 2017

pySU2 looks good to me!

@petebachant
Copy link
Contributor

If you guys are looking to follow PEP8, which is always nice, the package name would be all lowercase, i.e., pysu2.

@tobadavid
Copy link
Contributor Author

Thanks ! So do we go for pysu2 as the Py module and _pysu2 as the extended C++ (.so lib) ?

@economon
Copy link
Member

Thanks for the input, all, and for the final adjustment, David. Time to merge this in!

@economon economon merged commit 02627aa into develop Jan 18, 2017
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.

5 participants