Copy help information from onedim.py:setProfile to CounterFlame.py:setProfile and others

[GoogleCodeExporter]

Since I just spent far too much time to figure out how setProfile works in a 
CounterFlame, it would be great to get help on the basic functionality in the 
wrapping functions as well.
(I found specifying 'relative' positions for the flame grid not really 
intuitive;)

For the Counterflow Flame module, it might also be helpful to set locs to be
 self.flame.grid() / (self.flame.grid()[-1] - self.flame.grid()[0])
for the case that someone only wants to change previously obtained profile data.

Original issue reported on code.google.com by thetruet...@googlemail.com on 18 Jun 2012 at 12:34

[GoogleCodeExporter]

New in r1590: The docstrings for the base class methods are automatically 
copied to the derived classes.

If you can provide better docstrings for these functions then the current ones, 
I would gladly update them.

I'm not entirely sure I understand your last point. Where do you think this 
should be set? Do you want to be able to pass an unnormalized array as the pos 
argument to setProfile? That seems like a separate issue that can be revisited 
along with some other changes to the Python module's API after Cantera 2.0 is 
released.

Original comment by yarmond on 19 Jun 2012 at 4:51

• Changed state: InProgress
• Removed labels: OpSys-Linux

[GoogleCodeExporter]

Thanks, r1590 is exactly what I meant.
The only drawback is that now you have parameters listed in the docstring which 
are not available in the overwriting function. For example, help on 
OneD.CounterFlame.setProfile() will still show the parameter 'dom', which is 
not present in this function. This is also true for the example call.

After thinking about the second part of my issue, I think it's not that 
important.
I just had the case that I wanted to change a mass fraction profile to get a 
better starting guess. I did that by obtaining the array using profile(), 
directly manipulating the array, and finally using setProfile() to push it back 
into the solution vector. In order to correctly assigning the profile, I had to 
use the command I stated above to get the relative locations of the grid 
points, which are not given by default.
I somehow thought that this was like a standard procedure, and the part of 
obtaining the relative grid point locations was not intuitive, so I requested a 
default hint for this array.
However, I now think that this procedure is not that standard and only few 
people will ever think about it. The docstring on Stack.setProfile() is also 
quite helpful, so I don't think it's worth worrying too much about it.
Sorry for the confusion!

Original comment by thetruet...@googlemail.com on 20 Jun 2012 at 3:31

[GoogleCodeExporter]

I don't like the appearance of the extra parameter either, but I think it's 
better than having five copies of the docstring that gradually diverge.

Original comment by yarmond on 21 Jun 2012 at 8:06

• Changed state: Fixed