[Wikiversity-l] Moodle and software support for Wikiversity

[Brian Salter-Duke]

Hi Draicone, and everybody

On Mon, Dec 10, 2007 at 10:53:15AM +1000, draicone at gmail.com wrote:
> 
>    On Dec 10, 2007 7:05 AM, Brian Salter-Duke <[1]b_duke at bigpond.net.au>
>    wrote:
> 
>      1. The ability to display molecular models that can be manipulated
>      by the
>      reader. This function is available in an open source application
>      called
>      Jmol. A php extension is available to run in mediawiki and Jmol
>      does run
>      on, for example, the Jmol Wiki. I have tried to get this added to
>      Wikipedia, where of course it would also be useful, but the
>      technical
>      folks, think the php is not sufficiently free of security concerns.
>      I do
>      not know php but I am trying to get this issue solved.
>      Unfortunately the
>      author of the Jmol php extension is too busy to do this.
> 
>    If you can provide us with further details, I can get it started on
>    the sandbox wiki we have running on the server.

This sounds great. Give me a few days. The Jmol wiki has just been
upgraded and I have not had a chance to check things out there. I will
make sure I am clear about the latest versions of Jmol etc. I will also
point you to where you can see what it does. It involves installing Jmol
itself and then a php extension.

However, the security problem remains. I have discussed this in the past
with Tim Starling - see User:Tim Starling on the English Wikipedia. He
is employed by the Foundation as a Technical support person. He looked 
at the php code and said it did not satisfy him on security grounds. He 
will not allow it on the Foundation servers until those concerns are 
fixed. I do not know enough about it to fix them.  I will have
another go at getting someone to address the security concerns.

>      2. The real innovation of our materials is that they allow the user
>      to
>      prepare data for a variety of different computational chemistry
>      programs
>      and then run the data, either directly in real time, getting the
>      results
>      back on a web page, or by queueing the job if it is larger and
>      getting
>      the results back later on a web page or by e-mail. Our materials
>      use a
>      variety of quite complex CGI scripts that handle the materials from
>      html
>      forms and menus and then run the code. While queueing the jobs is
>      necessary in some cases, this is really only to restrict access to
>      the
>      disk for storing large temporary files. The CGI scripts prevent the
>      user
>      from entering large jobs. In this context "large job" equates to
>      "large
>      molecule" with the cpu time rising with some some power of the
>      molecular
>      size. For teaching, small molecules only are needed and these take
>      little
>      time. When a job is queued, for example, it leaves a URL link on
>      the
>      page returned by the CGI script. The user can keep clicking on it
>      until
>      it returns more than a header saying try again later.
>      While currently we use both open source and commercial codes, the
>      commercial codes can be replaced by open source ones by writing a
>      few
>      more CGI scripts.
>      This use clearly needs a server that can run these CGI scripts and
>      the
>      programs they call. It does not have to be the server that handles
>      the
>      forms page. For a while we ran one application 3000 km away from
>      the
>      main server.
> 
>    I've got a 40kg server with triple power supplies, dual CPUs, triple
>    hard drives and dual ear muffs to be able to hear with it all that we
>    might be able to use :) Let me know if this sounds okay and I'll get a
>    flavor of Linux up and running on it.

That sounds great. Yes, it would need linux and I would have to send you
a number of codes to install. However, until I know how we would run
them on a wiki, I can not progress this. We could have course have a
link that goes off the wiki to your server for the cgi scripts etc. That
might well be the best way to go.

The simplest method is the Huckel method. The code is my own and I can 
release it under a free license. The program is in Fortran and 
actually uses some CGI routines in Fortran. I got this running 
just for the hell of it. Someone said you can not write CGI scripts 
in Fortran as they have to be in C, perl or python. The program is 
itself the CGI script. In other cases of larger Fortran programs 
from elsewhere, the CGI script is in perl and calls the program after 
getting the data together.

The Huckel program is one of three used by our module 3. The second is
also a home written Fortran program. The third is a program called MOPAC
which exists in many flavours but one of them is open source. I would
want to get module 3 up among the first. 

Module 2 needs to make extensive use of Jmol. We are currently still
using a product called Chime which no longer works well with some
browsers. I need to convert the whole of that to Jmol and that would be
an early priority. Molecular images in all other modules are already
converted to Jmol. Module 1 is very old and out of date. I will not be
using that module.

Modules 5 and 8 use a program that is much bigger and takes longer to
run. However small molecules are reasonable. This module is about what 
is called ab initio quantum chemistry. It gives a choice of two
internationally well know programs. One is commercial. The other is free
but licensed - not open source. There are two open source ab initio
programs and I plan to test one of them on our servers soon. By test I
mean write CGI scripts to run it from web pages. It works on my linux
box at home and should work on the Monash University server.

>      I have no idea what the equivalent to CGI scripts is within
>      mediawiki
>      and how we can run forms (the quiz extension may be a start here),
>      but
>      I'm willing to learn. Whether this is feasable, I do not really
>      know.
>      However, I think that what I am suggesting could have wider use.
>      Wikiversity needs to have pages that are dynamic in ways that
>      wikipedia
>      does not need. Web based learning has to be more than reading text
>      and
>      looking at pictures on a computer screen. I think this is the
>      greatest
>      challenge for the technical people on wikiversity.
> 
>    One of the main purposes of the sandbox server was to allow us to
>    break out of the restrictions of MediaWiki. Forms in PHP are dead
>    easy. Even if you don't have a programming background you could learn
>    in half an hour. MediaWiki can have forms, but it requires some highly
>    complex code and a few hacks here and there. We would be developing
>    real applications to facilitate our learning systems, as opposed to
>    this reliance on MediaWiki for what clearly warrants a dedicated
>    application.

That sounds great.
 
>      There has been a suggestion that these kinds of computer
>      calculations
>      can be handled by distributed computing using users own PCs, rather
>      like
>      the SETI project. These could be usefull for very large jobs in
>      some
>      cases on WV, but I do not think they are suitable for my
>      applications
>      where we just need a few seconds (maybe up to 100 secs) on a linux
>      machine. Most of the codes we use are unix based. Distributing
>      computing
>      is not required and it would delay getting the response to the
>      learner.
> 
>    If it's a few seconds of calculations, why do we need a computer to do
>    it in the first place? Can't students run the algorithms on their own
>    machines? In any case, for a few seconds of calculation the overhead
>    of a distributed task system like SETI is totally out of the question,
>    a server would be best.

There are three reasons:-

1. These programs are massive, particularly the ab initio codes. For
real research projects they can run for days in parrallel. The time can
be proportion to n^4, n^5, or n^7 (depending on method) where n is a
measure of molecular size. Small molecules run quickly but they still
whiz through a lot of code.

2. We want students to get some familarity with real codes that they
will use later in research.

3. They run under linux. There are a few ab initio codes that run on
Windows but they are complex and I know none that are open source. Some
cost lots of money. The simple Huckel program could be converted to run 
on a PC, but it would still be quite a bother for the user to download 
it and set it up for a few calculations. The MOPAC code is also very 
large, even though it is not very computationally demanding. 

I agree about not using a distributed task system like SETI. I mentioned
it only because the last time I raised this, I was told that was the
way to go for this kind of think on wikiversity.

This is all very encouraging. If you are prepared to cooperate on this,
I think I can add some really usefull learning materials to Wikipedia
and perhaps give ideas to others while doing it.

Sorry my reply is rather long.

Regards, Brian.
 
>      I would welcome suggestions for dealing with this.
>      Brian.
> 
>    Let me know what you think of these.
>    Draicone
> 
> References
> 
>    1. mailto:b_duke at bigpond.net.au

> _______________________________________________
> Wikiversity-l mailing list
> Wikiversity-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikiversity-l

-- 
          Brian Salter-Duke            b_duke at bigpond.net.au  
               [[User:Bduke]]  mainly on en:Wikipedia.
           Also on fr: Wikipedia, Meta-Wiki and Wikiversity