SKILL Q: Accessing saved results from SKILL

S

Svenn Are Bjerkem

Guest
Hi,
when running ADE in distributed mode, ADE create a saved state for each
simulation. These can be chosen by using the Results->Select ... menu.

Now, I have been looking at setting the current results by SKILL, but I have
so far only found the sevSelectResults() function, which pops up the select
results form. That is not quite what I want. I am looking for something
like:

(foreach res (list "Cload-1pF" "Cload-pF")
(*hereComesTheWantedFunc* res)
(printf "%f %f\n"
(average (clip (VT "/out") 1e-8 1e-6))
(stddev (clip (VT "/out") 1e-8 1e-6))))

--
Svenn
 
Svenn Are Bjerkem wrote:
Hi,
when running ADE in distributed mode, ADE create a saved state for each
simulation. These can be chosen by using the Results->Select ... menu.

Now, I have been looking at setting the current results by SKILL, but I have
so far only found the sevSelectResults() function, which pops up the select
results form. That is not quite what I want. I am looking for something
like:

(foreach res (list "Cload-1pF" "Cload-pF")
(*hereComesTheWantedFunc* res)
(printf "%f %f\n"
(average (clip (VT "/out") 1e-8 1e-6))
(stddev (clip (VT "/out") 1e-8 1e-6))))

Hi Svenn,

I don t see why you use analog artist sevSelectResults() rather than
ocean selectResults()

try:
ocnHelp 'dataAccessHints
 
fogh wrote:

(foreach res (list "Cload-1pF" "Cload-pF")
(*hereComesTheWantedFunc* res)
(printf "%f %f\n"
(average (clip (VT "/out") 1e-8 1e-6))
(stddev (clip (VT "/out") 1e-8 1e-6))))

Hi Svenn,

I don t see why you use analog artist sevSelectResults() rather than
ocean selectResults()
When I run selectResults() on the CIW, it returns the name of the dierctory
where the result is that which I selected with Results->select ... in ADE.
But I have not found out how to use selectResults() to change from one
saved result to another. I'll have to read up on that in the ocean manual,
but I really would like to stay away from ocean if I can.

ocean wants me to set the design directory and the simulator and such up
front. My data is somewhere on the grid and I have to edit the design()
path every time I change grid computer. The way ocean macros work is quite
rigid in my sense.

Regards,
--
Svenn
 
When I run selectResults() on the CIW, it returns the name of the dierctory
where the result is that which I selected with Results->select ... in ADE.
This means the function succeeded.

But I have not found out how to use selectResults() to change from one
saved result to another.
openResults( "your/results/dir" )
selectResult( "dc" ) ; or "ac", "dcOp", or whatever...
; use getData, v, i, etc to retrieve your results
; of course, help and ocnHelp are your friends this time

I'll have to read up on that in the ocean manual,
but I really would like to stay away from ocean if I can.
why?

ocean wants me to set the design directory and the simulator and such up
front.
no... only if you want to run a simulation.

stéphane
 
S. Badel wrote:

A personal distaste for using ocean in a grid computing environment. When
using ADE in distributed mode it is very very easy to spawn off a job, give
the results from that job a feasible name, use the Results->select ...
function to select a particular simulation result and then let a script run
on the currently selected simulation results.

I guess you are aware that when using the results browser and left-click on
a node name, you get an expression like this:
v( "/node" ?result "tran-tran" ?resultsDir
"/share/machine/tmp/libName/cellView/spectre/config/distributed/M14B-real-10c-tline" )

due to the ?resultsDir, this is tied to a very particular result on a very
particular machine in my grid. If I go on and delete that ?resultsDir I get
an expression which is depending on the /currently selected results/ which
is always indicated at the bottom of the ADE window.

with v( "/node" ?result "tran-tran" ) I can now extract the same node
voltages from different sets of results by just changing the /currently
selected results/.

Currently I have to do the selecting of the /currently selected results/ by
hand before I let the skill script extract some statistical values, prints
them to a file that I can read with xmgrace for presentation purposes. I
was hoping that there was a way to manipulate that select results dialog
from skill directly so that I could do everything in a foreach loop.

no... only if you want to run a simulation.
Yes, but I have to give the _absolute_ path to the location of the psf data,
and the absolute path of the data is not feasible when you are working on a
grid where your simulation data is located on a share of the machine where
the icfb session is /currently/ running. This means that I would have to
modify my ocean scripts each time I get a different machine assigned.

This is no problem, I have written ocean scripts for that, but I have given
you my motivation for skill only above.

Regards,
--
Svenn
 
Svenn Are Bjerkem wrote:

Currently I have to do the selecting of the /currently selected results/ by
hand before I let the skill script extract some statistical values, prints
them to a file that I can read with xmgrace for presentation purposes. I
was hoping that there was a way to manipulate that select results dialog
from skill directly so that I could do everything in a foreach loop.
openResults()

prefix your code with openResults( "absolute/path" ), and do not provide ?resultsDir
in the subsequent calls. this way there's only one line to change each time (the first).

or, wrap the code in a procedure and make this path a parameter.

or, make up the path name with strcat( getShellEnvVar("ABSOLUTE_PATH") "/relative/path" )

This is no problem, I have written ocean scripts for that, but I have given
you my motivation for skill only above.
I do not understand "skill only". What difference do you make between skill and ocean?
Ocean is no more than a set of SKILL functions, or a. I do not see either how avoiding ocean
will make your life easier regarding this path issue.

cheers

stéphane
 
S. Badel wrote:

I do not understand "skill only". What difference do you make between
skill and ocean? Ocean is no more than a set of SKILL functions, or a. I
do not see either how avoiding ocean will make your life easier regarding
this path issue.
I personally do not make any difference between ocean and skill. ocean is to
me a collection of macros or procedures or whatever that in the end is
skill. An abstraction level which is supposed to make everyday life easier
for engineers who want to automate their simulations. That's also why ocean
can be started from the unix commandline without the need of the icfb
frontend. That is how _I_ see it. There is probably an official view and
loads of other personal views also.

When using the ocean macros, somebody has been thinking on behalf of me. In
this particular case, that thinking does not suit my application. All I
want to know is how to access the value that is normally set by interactive
call of the Select Results dialogue in a programmatical way. I know it is
possible to use openResults() but it would be simpler if I could access
that variable directly. I happened to find out that I can change
saved /state/ by manipulating
sevSession(hiGetCurrentWindow())->loadForm)->name->value for the Load State
Dialogue, why shouldn't it be possible to do the same with the Select
Results dialogue?

--
Svenn
 
Hi,
Badel is right. if you have a transient simulation you have to process
the following steps:
- selectResults('tran) or selectResults("tran")
- with outputs() you can view all possible currents and voltages (can
be a very long list if you saved all data)
- with value(getData("hier1.hier2.M0:1") 2p) you will get the drain
current of M0 in the hierarchy hier1/hier2 @ 2ps
- in our environment spectre does a terminal mapping so that is is
also possible to get the drain current of M0 with
value(getData("/hier1/hier2/M0/d"))
the information of the terminal mapping is located in the amap
directiory in ...simulationDir/netlist/amap

greetings,
hikom
 
Hi,
Badel is right. if you have a transient simulation you have to process
the following steps:
- selectResults('tran) or selectResults("tran")
- with outputs() you can view all possible currents and voltages (can
be a very long list if you saved all data)
- with value(getData("hier1.hier2.M0:1") 2p) you will get the drain
current of M0 in the hierarchy hier1/hier2 @ 2ps
- in our environment spectre does a terminal mapping so that is is
also possible to get the drain current of M0 with
value(getData("/hier1/hier2/M0/d"))
the information of the terminal mapping is located in the amap
directiory in ...simulationDir/netlist/amap

greetings,
hikom
 
In article <tq6dnQktV8Abwe_fRVn_vg@giganews.com>,
morgenst@izm.fhg-dot-de.no-spam.invalid (hikom) wrote:

Hi,
Badel is right. if you have a transient simulation you have to process
the following steps:
Of, course is he right. I don't question the correctness of the advice
on how to use the ocean macros. My question is how to perform the same
functionality *without* the ocean macros. I have also given a reason why
I would like to do it the way I want to. If somebody would tell me that
it is not possible to do it *any* other way, then I would accept that
and go on using openResults() and friends.

Kind regards,
--
Svenn
 
On Fri, 29 Apr 2005 17:13:41 +0200, Svenn Are Bjerkem <svenn.are@bjerkem.de>
wrote:

S. Badel wrote:

I do not understand "skill only". What difference do you make between
skill and ocean? Ocean is no more than a set of SKILL functions, or a. I
do not see either how avoiding ocean will make your life easier regarding
this path issue.

I personally do not make any difference between ocean and skill. ocean is to
me a collection of macros or procedures or whatever that in the end is
skill. An abstraction level which is supposed to make everyday life easier
for engineers who want to automate their simulations. That's also why ocean
can be started from the unix commandline without the need of the icfb
frontend. That is how _I_ see it. There is probably an official view and
loads of other personal views also.

When using the ocean macros, somebody has been thinking on behalf of me. In
this particular case, that thinking does not suit my application. All I
want to know is how to access the value that is normally set by interactive
call of the Select Results dialogue in a programmatical way. I know it is
possible to use openResults() but it would be simpler if I could access
that variable directly. I happened to find out that I can change
saved /state/ by manipulating
sevSession(hiGetCurrentWindow())->loadForm)->name->value for the Load State
Dialogue, why shouldn't it be possible to do the same with the Select
Results dialogue?
Not really understood why you want to overcomplicate things and use functions
other than OCEAN. OCEAN is intended to be the API for doing this sort of
thing.

Note that if you submit jobs using the distrbuted processing option, you can
open the results using openResults(jobName) . See ocnHelp('openResults) for
more details, as well as the OCEAN documentation.

That means you don't have to know exactly the path that was used...

Regards,

Andrew.
 
Svenn Are Bjerkem wrote:
Hi,
when running ADE in distributed mode, ADE create a saved state for each
simulation. These can be chosen by using the Results->Select ... menu.

Now, I have been looking at setting the current results by SKILL, but I have
so far only found the sevSelectResults() function, which pops up the select
results form. That is not quite what I want. I am looking for something
like:

(foreach res (list "Cload-1pF" "Cload-pF")
(*hereComesTheWantedFunc* res)
(printf "%f %f\n"
(average (clip (VT "/out") 1e-8 1e-6))
(stddev (clip (VT "/out") 1e-8 1e-6))))
Hi Svenn,

It got a bit clearer thanks to the discussions. It seems you want to
use the artist session info to get the location of your results, because
you can not get that easily from your queueing system.
It should be something like this (disclaimer: I did not test it) :

procedure(HereIsTheWantedFunc(res)
openResults(
strcat(
asiGetResultsDir(asiGetCurrentSession())
"/../"
res
)
)
)

You are using VT , and that is a bit risky. I suggest you use
selectResult('tran) also in your script.
 
In article <4273c48a$0$158$e4fe514c@news.xs4all.nl>,
fogh <adff@xs4all.nl> wrote:

It got a bit clearer thanks to the discussions. It seems you want to
use the artist session info to get the location of your results, because
you can not get that easily from your queueing system.
Andrew "forced" me to read the ocean manual a bit closer on run() and
openResults() and this, instead of some examples I have used up to now,
shows that in distributed mode, it should be possible to use the
assigned job name independently of the location of the data, just like I
wanted to do according to my original specification.

It should be something like this (disclaimer: I did not test it) :

procedure(HereIsTheWantedFunc(res)
openResults(
strcat(
asiGetResultsDir(asiGetCurrentSession())
"/../"
res
)
)
)
This example looks promising. I'll see what I can make out of it.

You are using VT , and that is a bit risky. I suggest you use
selectResult('tran) also in your script.
Good idea, I have so far been working transient only and I was not aware
that VT alone can cause problems.


Kind regards,
--
Svenn
 
Svenn Are Bjerkem wrote:
In article <4273c48a$0$158$e4fe514c@news.xs4all.nl>,
fogh <adff@xs4all.nl> wrote:


It got a bit clearer thanks to the discussions. It seems you want to
use the artist session info to get the location of your results, because
you can not get that easily from your queueing system.


Andrew "forced" me to read the ocean manual a bit closer on run() and
openResults() and this, instead of some examples I have used up to now,
shows that in distributed mode, it should be possible to use the
assigned job name independently of the location of the data, just like I
wanted to do according to my original specification.


It should be something like this (disclaimer: I did not test it) :

procedure(HereIsTheWantedFunc(res)
openResults(
strcat(
asiGetResultsDir(asiGetCurrentSession())
"/../"
res
)
)
)


This example looks promising. I'll see what I can make out of it.


You are using VT , and that is a bit risky. I suggest you use
selectResult('tran) also in your script.


Good idea, I have so far been working transient only and I was not aware
that VT alone can cause problems.
VT is a calculator function, so you are not supposed to use it if you
do "ocean only" code.

It is quite normal that Andrew convinced you , since he was -as usual-
right ...
 
fogh wrote:

VT is a calculator function, so you are not supposed to use it if you
do "ocean only" code.
Ok, then it is not valid for my script because I do not work in "ocean mode
only". I work in ADE mode and have the calculator available. I have to
measure a lot of parameters and I do this by scripting.

--
Svenn
 
On Mon, 02 May 2005 11:48:14 +0200, Svenn Are Bjerkem <svenn.are@bjerkem.de>
wrote:

fogh wrote:

VT is a calculator function, so you are not supposed to use it if you
do "ocean only" code.

Ok, then it is not valid for my script because I do not work in "ocean mode
only". I work in ADE mode and have the calculator available. I have to
measure a lot of parameters and I do this by scripting.
The point is that VT() does not necessarily work properly in OCEAN scripts -
mainly for historical reasons.

I always think it's better to use v("/netName" ?result 'tran) - this will work
in ADE and OCEAN. Or if you've done selectResult('tran) first, you don't need
the ?result argument to v().

There's a PCR to get the VT, IT, VF, IF, etc functions to use the OCEAN
functions underneath (they don't at the moment because they pre-date OCEAN),
which would probably resolve the problem where sometimes these ADE calculator
functions don't work in OCEAN.

So it's not so much if you do "ocean only" code - but more to do with if you
use OCEAN at all...

Regards,

Andrew.
 
Andrew Beckett wrote:

So it's not so much if you do "ocean only" code - but more to do with if
you use OCEAN at all...
As OCEAN is both an API and a command line program I think /use OCEAN/ is
quite confusing. I use the OCEAN application to script simulations and
result extractions where I do not use the schematic capture GUI. I can also
use the OCEAN API on the CIW line as any other SKILL command because OCEAN
is SKILL.

My experience so far is that OCEAN works very well when using it to script
the OCEAN application (automated simulation). When using the OCEAN API on
the CIW command line, I have problem getting the described functionality of
the command. My current problem, changing between results from simulations
in 'distributed' mode, is an example where I find this really frustrating.

Even after reading the manual the confusion and frustration does not settle.
openResults() can take either a job name or a path to the result. But to me
it looks like that job name must be assigned by run( ?jobName ) because
run() returns a 'jobName thingie that I can use with openResults() to open
that particular set of simulation outputs.

Now, to the way I work: I use the calculator to select and plot results.
This is quite convenient because I can cut-and-paste calculator expressions
from a text cellview that is stored with the schematics. This way I can
repeat simulations weeks later and still know what was important to check,
because I can just go through that text file and cut-and-paste into the
calculator and plot. This is the reason why I use calculator syntax and not
OCEAN syntax on my waveform expressions. It takes too long time to rewrite
them (and this is also error prone). If I like the results of the plot, I
just copy-and-paste the expression in the calculator window to my text
documentation window, write some comments and save. Next item.

This way of working may seem pretty awkward, but after long experiments with
the software, I find it very convenient. The scripts that I want to write,
which started this discussion, are also supposed to land into this text
cellview so that I can improve them when needed before pasting them into
the CIW. I was once focused on attaching my procs to menus and such, but
then, after some time, the script reduces from being a script to becoming
an element in a menu, and to find the functionality of the menu item I have
to go looking for the source code. Documentation of scripts is something
CAD support does. My scripts are so small that they are documentation in
themselves.

--
Svenn
 
fogh wrote:

procedure(HereIsTheWantedFunc(res)
openResults(
strcat(
asiGetResultsDir(asiGetCurrentSession())
"/../"
res
)
)
)
By the way, where is asiGetResultsDir() documented? There's nothing on
sourcelink or in the finder.

--
Svenn
 
On Tue, 03 May 2005 08:52:59 +0200, Svenn Are Bjerkem <svenn.are@bjerkem.de>
wrote:

By the way, where is asiGetResultsDir() documented? There's nothing on
sourcelink or in the finder.

--
Svenn
It's a private function. Don't use it...

Andrew.
 
On Tue, 03 May 2005 08:26:28 +0200, Svenn Are Bjerkem <svenn.are@bjerkem.de>
wrote:

Andrew Beckett wrote:

So it's not so much if you do "ocean only" code - but more to do with if
you use OCEAN at all...


As OCEAN is both an API and a command line program I think /use OCEAN/ is
quite confusing. I use the OCEAN application to script simulations and
result extractions where I do not use the schematic capture GUI. I can also
use the OCEAN API on the CIW line as any other SKILL command because OCEAN
is SKILL.
That's why I always distinguish between "ocean" (the executable) and "OCEAN"
(the API).

My experience so far is that OCEAN works very well when using it to script
the OCEAN application (automated simulation). When using the OCEAN API on
the CIW command line, I have problem getting the described functionality of
the command. My current problem, changing between results from simulations
in 'distributed' mode, is an example where I find this really frustrating.
There should be no difference with using OCEAN API functions in the CIW and
using it in the ocean executable - with the exception that there are a small
number of things you can do in the CIW but not in the ocean executable (e.g.
design(libName cellName viewName) rather than an existing netlist).

Even after reading the manual the confusion and frustration does not settle.
openResults() can take either a job name or a path to the result. But to me
it looks like that job name must be assigned by run( ?jobName ) because
run() returns a 'jobName thingie that I can use with openResults() to open
that particular set of simulation outputs.
No. The run() function will return the jobname regardless of whether ?jobName
was specified or not (if you're in distributed mode). All that ?jobName allows
you to do is choose the root of the generated job name - you should always use
the return value to find out what job name was actually used.

Even if you always pass ?jobName to run(), the generated run name may be
different because it needs to be unique.

Now, to the way I work: I use the calculator to select and plot results.
This is quite convenient because I can cut-and-paste calculator expressions
from a text cellview that is stored with the schematics. This way I can
repeat simulations weeks later and still know what was important to check,
because I can just go through that text file and cut-and-paste into the
calculator and plot. This is the reason why I use calculator syntax and not
OCEAN syntax on my waveform expressions. It takes too long time to rewrite
them (and this is also error prone). If I like the results of the plot, I
just copy-and-paste the expression in the calculator window to my text
documentation window, write some comments and save. Next item.
I understand. This is entirely why we need to fix the problem where VT, etc
don't work properly in OCEAN (sometimes...). They work in simple situations,
but tend to break with more advanced analyses (monte carlo, for example).

I always recommend people to do the data access by using the direct plot->
main form, and then the "add to outputs" option on this form to add to the ADE
outputs pane. Then steal the expression from there. These expressions are
generally OCEAN friendly, and also don't have the ?resultsDir bits that the
results browser adds.

Regards,

Andrew.
 

Welcome to EDABoard.com

Sponsor

Back
Top