Re: [Ngspice-users] Questions on Parallelizing NGSPICE

[Stuart B. <sd...@cl...>]

Hi --

On Tue, 5 Dec 2006, praneet wrote:

> Hello Everyone,
>
> We at Sun Microsystems just got started with NGSPICE.

That's cool!

>  1. I downloaded and used ng-spice-rework-17.tar.gz. Can someone
>     please confirm if this is the latest code for the app.

That's right.  rework-17 is the latest release.

>  2. As Sun Grid runs on Solaris 10 X86, I tried compiling the code on
>     x86 and faced problems with a status variable on line number  176
>     of src/frontend/aspice.c. I'd to insert a dummy statement there.
>     Is it a known issue? Is the commenting out going to materially
>     impact the running of application? I am pasting the code here:      :-(
>                                                                                                               171 
> #if defined(__NetBSD__) || defined(SOLARIS)
>        172      pid_t status;
>        173  #elif defined(__FreeBSD__) || defined(__APPLE__)
>        174      int status;
>        175  #else
>        176   /*    union wait status; */ */*THIS CREATES PROBLEMS,
>     COMPILER SAYS STORAGE ALLOCATION FOR WAIT CANT BE DETERMINED, I
>     COMMENTED THIS OUT AND PASTED THE ONE BELOW */
>     *   177   int status;  /* Anyways, we are running solaris!!! */
>        178
>        179  #endif

I imagine you are compiling with a Sun compiler (as opposed to gcc)?
If so, it's likely that little issues lurk in the code since I am not
aware of many people working on ngspice using a Sun compiler.

If you can make it work for your compiler, and also test it with gcc
to verify that nothing broke, then you're encouraged to go ahead and
make the changes.

>  3. Coming to the crux of the matter -
>        1.  Has there been any attempt in the past to make the app fit
>           for distributed computing?

I believe there has.  If you look through the source, there are some
#ifdef lines asking for PARALLEL_ARCH, or something like that.  Try
grepping for PARALLEL in the source.  However, I don't believe that
particular porting effort ever came to fruition.  But I am not an
expert on this particular issue.

>        2.  Is it better to  concentrate on the application or on
>           libraries?

Here it depends upon what you want to do.  If you're interested in
creating a task-parallel version of ngspice, then porting the whole
app makes sense.  Moreover, in that case it makes sense to make sure
ngspice can communicate reliably via pipes or some other IPC
mechanism.  (i.e. With pipes make sure it flushes the buffer after
every output line, etc.)

If you're interested in creating a data-parallel version, then you're
going to spend most of your time on integrating MPI calls into the
libraries so as to handle gigantic matricies.  Then you can firm up
the interface between the back-end solver libraries and the front end
console so that the libraries may eventually be called from other
programs.

Since you're porting it to the Sun grid, I expect you intend to create
a task-parallel version, right?

>        3.  Does the application lend itself to data portioning, that
>           is making the same spice code run on all the machines in the
>           grid ,giving chunks of data to all nodes and merging the
>           output?

No, not yet.

4. Are there any algorithms known in public 
> domain, whch if implemented would make ngspice 
> fit/fitter for distributed computing?

Again, it depends upon what kind of distributed computing you have in
mind.  If it's just launching separate versions of ngspice across a
grid, then there isn't much you really need to do, except make sure
ngspice can communicate reliably via some IPC mechanism.  If you're
vision involves a data-parallel ngspice, then there are various
parallel versions of linear solvers out there (SCALAPAK and LANPAK come
to mind as possibilities) which you could bolt into ngspice, although
that is a lot of work, and is again not really a good fit with grid
computing.

> Any ideas, thoughts, comments even criticisms would be heartily welcome.

If you aren't allergic to the GPL, you could take a look at gnucap.
It's a different analog simulator which reads SPICE netlists.
The code is more modern and cleaner (ngspice is a complicated mess).
It also allows for event-driven simulation as well time-driven.  OTOH,
it's missing a few models (JFETs in particular).

> Anything else that you think may enlighten us would be deeply appreciated.

Make sure you compile in the XSpice extensions to enable folks to use
SPICE2 POLY constructs.

Also make sure you get the ADMS stuff compiled in, since it adds
modern Verilog-AMS functionality.  This is the wave of the future, so
getting it into ngspice will attract a lot of interest.

Cheers,

Stuart