<div>"Its normally better to change the values in place"<br> </div>
<div>So you mean I should use VecSetValue/s instead?</div>
<div> </div>
<div>Thank you.</div>
<div> </div>
<div>Regards.<br> </div>
<div><span class="gmail_quote">On 12/4/06, <b class="gmail_sendername">Matthew Knepley</b> <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On 12/4/06, Ben Tay <<a href="mailto:zonexo@gmail.com">zonexo@gmail.com</a>> wrote:<br>><br>> Hi,
<br>><br>> regarding qn 4 ie the requirement of<br>> VecAssemblyBegin,VecAssemblyEnd, I used VecPlaceArray,<br>> VecResetArray to change the values. I did not use Assembly after the 1st<br>> time step and it works ok. So that is fine too, right?
<br><br>Its alright, but probably not optimal. It could result in slower code<br>due to all the<br>allocation. Its normally better to change the values in place.<br><br> Matt<br><br>> Thank you!<br>><br>> On 12/4/06, Satish Balay <
<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>> wrote:<br>> > On Sun, 3 Dec 2006, Matthew Knepley wrote:<br>> ><br>> > > > 1. Are petscscaler the same as real nos.? I am writing in double
<br>> precision<br>> > > > or real(8). So are these 2 interchangeable? (same as petscint and<br>> integer).<br>> > ><br>> > > Yes.<br>> ><br>> > You can check these defines in include/finclude/petscdef.h
<br>> ><br>> > PetscInt -> integer*4<br>> > PetscScalar -> real*8<br>> ><br>> > ><br>> > > > 2. while linking in compaq visual fortran, I get the warning message<br>> about
<br>> > > > conflict library with LIBCMT. Is it important or can I just ignore it?<br>> > ><br>> > > This is determined by your configure. Satish will know better how to<br>> control<br>> > > it.
<br>> ><br>> > There are some warnings because of the way compqaq f90 tries to<br>> > workarround some bugs in Visual Studio 6 version of the libraries. It<br>> > will be fine as long as all code [PETSc & application] is compiled
<br>> > with the same set of compiler options,<br>> ><br>> > ><br>> > > > 3. I am writing in f90 free form format. When I modify from fixed f77<br>> format<br>> > > > to f90, it gives me a lot of error, which seems to be the include file
<br>> > > > error. So, is it possible to write in f90 format?<br>> > ><br>> > > Depending on which compiler you use, you might have to give a flag. For<br>> g95<br>> > > it is -ffree-form.
<br>> ><br>> > We'll have to see the error messgaes to determine what the problem is<br>> > - however - if you check the PETSc fortran examples - they comply with<br>> > both fixed and free from syntax.
<br>> ><br>> > > > 4. I am writing a Navier stokes solver and I'm using PETSC to solve<br>> the<br>> > > > poisson eqn. If only the RHS changes with each time step, do I need to<br>> call
<br>> > > ><br>> > > > VecCreateSeq<br>> > > > <insert values in RHS b><br>> > > > VecAssemblyBegin<br>> > > > VecAssemblyEnd<br>> > > > VecDestroy
<br>> > > ><br>> > > > at each time step? I don't think I can (or I should) change values of<br>> b<br>> > > > after VecAssemblyBegin,VecAssemblyEnd, or can I?<br>> > ><br>> > > You can just change the values. Call AssemblyBegin/End() after each
<br>> group<br>> > > of changes.<br>> ><br>> > Another note: - If you change values with VecSetValues() - you'll need<br>> > to call VecAssemblyBegin,VecAssemblyEnd. However if you<br>> do
<br>> > VecGetArray() [or VecGetArrayF0()] - and change values - then you<br>> > don't need the calls to VecAssembly...<br>> ><br>> > Satish<br>> ><br>> ><br>><br>><br><br><br>--<br>
"Failure has a thousand explanations. Success doesn't need one" -- Sir<br>Alec Guiness<br><br></blockquote></div><br>