Inline an crossline segments

[mkx...@gmail.com]

Hello OpendTect Developers, Developers, Developers!
I am currently developing a plugin for OpendTect.
OpendTect 6.0.7, VS 2013 Update 5, Survey_F3_Demo_Training_v6

When I do a calculation of my Attribute for Z-slice all seems fine, but as you can see on the picture, when I do the same at In-Line and Cross-line I get a somehow weird output. The inline and cross-line is separated in four segments and after scratching my neck for some days my colleague realized the following: The number of segments is directly related to the number of processor-cores. Testing it on a machine with 8 cores and 16 cores (same code) showed 8 and 16 segments respectively.
Has someone an idea how to resolve this, even when its maybe not directly related to my code? I know, that's not much info, but maybe this "problem" is already known, and (hopefully) "just" a small bug in OpendTect.

With best regards

Martin

Another question: 
Currently, while developing the plugin, I do it the conservative way: I load my two dll's into OpendTect, then I chose Analysis->Attribute->3d and then select my plugin. As a next step I would like to make a pic-Button in OpendTect (like e.g. the SEG_Y import button or the "Edit Attributes"-Button with an own logo, which should trigger e.g. the Analysis->Attribute->3D class with my plugin already pre-selected. Since I've sometimes a hard time to find the correct classes in OpendTect, maybe someone could give me a hint for this "problem".

Thanks much in forward
Martin

[Wayne Mogg]

You control the use of parallel processing in OpendTect attributes by changing the return value of the allowParallelComputation method that is inherited from the Provider class. Including the following in the c++ header definition of your attribute class will disable multiprocessing.

bool allowParallelComputation() const

{ return false; }

As to your second question, if all you want is to have a custom attribute set loaded when you start OpendTect then the easiest solution would be to use a Command Driver script that loads the attribute set on startup. See the Command Driver documentation http://doc.opendtect.org/6.0.0/doc/od_userdoc/Default.htm#appendix_b-command_driver_manual.htm%3FTocPath%3D_____13 for details. 

Wayne

--
You received this message because you are subscribed to the Google Groups "OpendTect Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@opendtect.org.
To post to this group, send email to devel...@opendtect.org.
Visit this group at https://groups.google.com/a/opendtect.org/group/developers/.
To view this discussion on the web visit https://groups.google.com/a/opendtect.org/d/msgid/developers/ab696ede-3c61-458b-95f8-ce92ca856cc9%40opendtect.org.
For more options, visit https://groups.google.com/a/opendtect.org/d/optout.

[Raman Singh]

Hi Martin,

What Wayne suggested would indeed turn off multi-threading and you would get rid of the 'segments'. But that would only circumvent the problem you have in your implementation. It is the function computeData that is multi-threaded as you can see it has got an argument for thread index. What you need to do is be careful about the sample indices. For attribute processing, each trace is distributed to all the available threads. That means for each trace the function computeData is called as many times as the number of threads. For each of these calls the arguments 'z0' and 'nrsamples' define which samples are handled in that thread. 'z0' is the index of the starting sample and 'nrsamples' the number of samples for that particular thread. Therefore the functions getInputValue and setOutputValue also have 'z0' as an argument. As an example, you can take a look at Tutorial::computeData function in our tutorial plugin here:
https://github.com/OpendTect/OpendTect/blob/od6.0/plugins/Tut/tutorialattrib.cc

To answer your second question, I am afraid we do not have a readily available example. But I can give you some pointers on how to do it.

Let us say you have a class called YourPluginMgr to handle these peripheral things. Then the following line would add an icon to the OpendTect main window. Put the icon file (say your_icon_name.png) in data/icons.Default folder of your OpendTect installation.

dGBMenuMgr().pluginToolBar().addButton( "your_icon_name",
                toUiString("Text ToolTip For the Icon"),
                mCB(this,YourPluginMgr,openAttribWinCB) );

Then in the body of the function YourPluginMgr::openAttribWinCB( CallBacker* ) you can do something like this:

Attrib::DescSet* ads = Attrib::eDSHolder().getDescSet( false, false );
// Get hold of the global AttributeSet.

Attrib::Desc* newdesc = Attrib::PF().createDescCopy( "MyNewAttribute" );
// Create an instance of your attribute, say MyNewAttribute.

ads->addDesc( newdesc );
// Add this instance to the global set.

ODMainWin()->applMgr().editAttribSet( false );
// And finally launch the attribute window with this attribute already defined.

I hope this helps.

Best regards,
Raman

Raman K Singh

Manager Software Development

______________________________

dGB Earth Sciences, India
Phone:	+91 22 25704984
E-mail:	raman...@dgbes.com
Internet:	dgbes.com

SEG Distinguished Achievement Award 2016
______________________________

--
You received this message because you are subscribed to the Google Groups "OpendTect Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@opendtect.org.

[mkx...@gmail.com]

First of all: Thanks a lot, Raman, and also Wayne for your answers.

It's true, I got rid of the segments with Wayne's suggest, but of course it let me think if this could be the ultimate solution just to use one thread. I'll take a closer look in my computeData function, when I'm at work again.
To my 2nd "problem": So far Ive made something like this (in my uixxx_pi file, where I made a "Manager"-function to handle things like adding a menu):

    uiToolBar* tb = new uiToolBar(appl_, "My Toolbar");
    const CallBack tbbtncb(mCB(this, uiDirGLCMManager, tbBtnClicked));
    uiToolButtonSetup tbbtn("myicon", tr("Supertip"), tbbtncb);
    tb->addButton(tbbtn);
    appl_->addToolBar(tb);

Your suggestion, Raman, looks more promising, because in fact I don't need an own toolbar. Adding the icon just right to the other icons below the menu-bar is that, what I really wanted. And then my tbBtnClicked-function should simply launch the Edit attributes (3D) with my plugin already pre-selected, and not a "random" plugin.

As mentioned, I'm currently not at work, but I will give a feedback after trying my best.
Again, thanks very much and best regards
Martin