gmes-user — General discussion and queries about GMES for users.

[gmes-user] Release Announcement: GMES 0.9.5

[전경원 <kw...@gi...>]

Dear gmes users,

This release is just for the minor bug fixes.

Best regards.

[gmes-user] GMES 0.9.4 Release Announcement

[전경원 <kw...@gi...>]

Dear GMES users

I uploaded version 0.9.4. The change logs are follows.


   - Boundary class was renamed to Shell class, and can be set the 'center'
   and 'size'.
   - The scripts in 'tests' and 'examples' directories were cleaned up.

[gmes-user] GMES 0.9.3 Release Announcement

[전경원 <kw...@gi...>]

Dear GMES users.

Hi. GMES 0.9.3 was released. The change log follows.

   - The default width of Continuous source was changed to five times of
   the inverse frequency.
   - It is fixed that TotalFieldScatteredField.init does not call the
   _aux_fdtd.init.
   - FDTD provides the new helper function: write_field_all.

Re: [gmes-user] GAMES 0.9.1 Release Announcement

[전경원 <kw...@gi...>]

Hmmm.. The auto correction prefers GAMES to GMES.

2012/9/9 전경원 <kw...@gi...>

> Dear GMES users
>
> Hi. This release is for the urgent fixes of several bugs in the version
> 0.9. The list of bug fixes follows.
>
>    - The lack of generation control of material.py.
>    - Wrong usage of space differentials in the transparent sources
>    (TotalFieldScatteredField, GaussianBeam)
>    - Name conflict of DcpAde types.
>    - Several minor bugs
>
> Also, I should mention that the DcpAde class diverges, so please use
> DcpPlrc class if you need Drude-critical point implementation.
>
> Regards.
>

[gmes-user] GMES 0.9.2 Release Announcement

[전경원 <kw...@gi...>]

Hi, GMES users.

The following is the change list of the version 0.9.2.

* DcpAde class was replaced with the new implementation.
* The bug that the periodic boundary condition does not work on single
process execution was fixed.
* GMES provides a way to dump the electric and magnetic fields.
* Minor bug fixes.

Regards.

[gmes-user] GAMES 0.9.1 Release Announcement

[전경원 <kw...@gi...>]

Dear GMES users

Hi. This release is for the urgent fixes of several bugs in the version
0.9. The list of bug fixes follows.

   - The lack of generation control of material.py.
   - Wrong usage of space differentials in the transparent sources
   (TotalFieldScatteredField, GaussianBeam)
   - Name conflict of DcpAde types.
   - Several minor bugs

Also, I should mention that the DcpAde class diverges, so please use
DcpPlrc class if you need Drude-critical point implementation.

Regards.

[gmes-user] bug report

[전경원 <kw...@gi...>]

Dear gmes-users.

The release 0.9 has a bug at GaussianBeam source, thus users can not use
it. This bug has been fixed in the trunk version.

Regards.

[gmes-user] bug report

[전경원 <kw...@gi...>]

Dear gmes users.

I found that the auxiliary differential equation (ADE) implementation of
Drude-Critical Points (DCP) model, DcpAde is unstable. Please, use DcpPlrc
only if you want to use DCP implementation.

Regards.

[gmes-user] GMES 0.9 Release Announcement

[전경원 <kw...@gi...>]

Dear gmes users.

The significant change of this release is the stepping speed. The stepping
speed has been improved almost 4 times. Also, the memory usage was greatly
improved. However, the initialization process takes too long times, so may
be gmes still inadequate to the 3D simulation.

Also, there are various interface changes which you can check through the
examples and unit tests.

Bye.
Regards.

Re: [gmes-user] The first posting

[전경원 <kw...@gi...>]

Hi.

The memory locality fix are committed to the trunk. Now you can enjoy the
speed of GMES. I'm planning the release of version 0.9.

Regards.

2012/8/21 전경원 <kw...@gi...>
>
> Also, there is a change in attributes of 'PwMaterial' class. It just saves
> sequence of index, and its concrete class save the sequence of
> 'PwMaterialParam'. These sequences use std::vector as a container which
> provides a contiguous storage. To make the contiguous storage of
> 'PwMaterialParam', GMES stores 'PwMaterialParam' instances, not the pointer
> of it.
>
> These changes increased the stepping speed almost 5 times. Now, the source
> in the trunk only reflects the virtual function changes. The memory
> locality fixes will be updated soon, also.
>

[gmes-user] The first posting

[전경원 <kw...@gi...>]

Hi. I am the developer of GMES, Kyungwon Chun.

>From now on, I'll report the development progress and plan of GMES, through
this mailing list to guide any one who is interested.

These days, I've tried to accelerate the time-stepping speed. The direction
of work is adjusting virtual method level to reduce overhead of vtable look
up and increasing memory locality for the cache hit ratio. The PwMaterial
abstract base class lost its virtual method, 'update', and the 'update_all'
method became the new virtual method. This change reduce the number of
vtable lookup to just one for PwMaterial, for one time-step.

Also, there is a change in attributes of 'PwMaterial' class. It just saves
sequence of index, and its concrete class save the sequence of
'PwMaterialParam'. These sequences use std::vector as a container which
provides a contiguous storage. To make the contiguous storage of
'PwMaterialParam', GMES stores 'PwMaterialParam' instances, not the pointer
of it.

These changes increased the stepping speed almost 5 times. Now, the source
in the trunk only reflects the virtual function changes. The memory
locality fixes will be updated soon, also.

See you.