sets FC (if not set)
to F77.
Kind regards,
Matthias Jurenz
On 05.08.2014 02:40, Paul Hargrove wrote:
I noticed that Open MPI is passing
--with-openmpi-inside=1.7
in the arguments passed to
ompi/contrib/vt/vt/configure
and
ompi/contrib/vt/vt/extlib/otf/configure
The extlib/otf ca
ww.open-mpi.org/community/lists/devel/2014/07/15134.php
--
Matthias Jurenz
Technische Universität Dresden
Center for Information Services and High Performance Computing (ZIH)
01062 Dresden, Germany
Phone: +49 (351) 463-31945
Fax: +49 (351) 463-37773
E-Mail: matthias.jur...@tu-dresden.de
725:15: error: 'vt_cupti_events_enabled' undeclared (first use
> in this function) vt_cudart.c:2725:15: note: each undeclared identifier is
> reported only once for each function it appears in
FYI, this issue is fixed in revision 29754. Thanks for the hint Jörg!
Kind regards,
Matthias
mean the $(LN_S) loops for the PMPI interface. We will have a
look into this. Thanks.
- Bert
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Matthias Jurenz
Technische Universität
me to retest on PGI-7.2-5?
>
> -Paul
>
> On Thu, Sep 13, 2012 at 3:37 AM, Matthias Jurenz
>
> wrote:
> > On Wednesday 12 September 2012 17:16:48 Paul Hargrove wrote:
> >> Solaris and NetBSD platforms which displayed the VT Makefile error w/
> >> 1.6.2rc2 h
gt; - Fix VT compile problems
> >
> > --
> > Jeff Squyres
> > jsquy...@cisco.com
> > For corporate legal information go to:
> > http://www.cisco.com/web/about/doing_business/legal/cri/
> >
> >
> > ___
> &
Hello Mike,
could you please compile with enabled verbosity: make V=1
The missing symbols belong to libz which is a dependency library of
ompi/contrib/vt/vt/extlib/otf/otflib/libotf.la - i.e. libotf.la should contain
the following line:
dependency_libs='-L -lz'
If not, Libtool seems to be b
kes no difference when binding for exclusive
caches.
Matthias
On Thursday 15 March 2012 17:10:33 Jeffrey Squyres wrote:
> On Mar 15, 2012, at 8:06 AM, Matthias Jurenz wrote:
> > We made a big step forward today!
> >
> > The used Kernel has a bug regarding to the share
thias Jurenz wrote:
> It's a SUSE Linux Enterprise Server 11 Service Pack 1 with kernel version
> 2.6.32.49-0.3-default.
>
> Matthias
>
> On Friday 09 March 2012 16:36:41 you wrote:
> > What OS are you using ?
> >
> > Joshua
> >
> &
It's a SUSE Linux Enterprise Server 11 Service Pack 1 with kernel version
2.6.32.49-0.3-default.
Matthias
On Friday 09 March 2012 16:36:41 you wrote:
> What OS are you using ?
>
> Joshua
>
> - Original Message -----
> From: Matthias Jurenz [mailto:matthias.jur..
aches (e.g. core 0 and 2) I get
constant latencies ~1.1us
Matthias
On Monday 05 March 2012 09:52:39 Matthias Jurenz wrote:
> Here the SM BTL parameters:
>
> $ ompi_info --param btl sm
> MCA btl: parameter "btl_base_verbose" (current value: <0>, data source:
> de
23:32 George Bosilca wrote:
> Please do a "ompi_info --param btl sm" on your environment. The lazy_free
> direct the internals of the SM BTL not to release the memory fragments
> used to communicate until the lazy limit is reached. The default value was
> deemed as reasonable a
elps?
>
> Yes, I did - I answered as well. Our mail server seems to be something busy
> today...
>
> Just for the record: Using hwloc-1.4 makes no difference.
>
> Matthias
>
> > On Mar 2, 2012, at 8:26 AM, Matthias Jurenz wrote:
> > > To exclude a possibl
. Our mail server seems to be something busy
today...
Just for the record: Using hwloc-1.4 makes no difference.
Matthias
>
> On Mar 2, 2012, at 8:26 AM, Matthias Jurenz wrote:
> > To exclude a possible bug within the LSF component, I rebuilt Open MPI
> > without support for LSF (-
To exclude a possible bug within the LSF component, I rebuilt Open MPI without
support for LSF (--without-lsf).
-> It makes no difference - the latency is still bad: ~1.1us.
Matthias
On Friday 02 March 2012 13:50:13 Matthias Jurenz wrote:
> SORRY, it was obviously a big mistake
Matthias
On Tuesday 28 February 2012 13:36:56 Matthias Jurenz wrote:
> When using Open MPI v1.4.5 I get ~1.1us. That's the same result as I get
> with Open MPI v1.5.x using mpi_yield_when_idle=0.
> So I think there is a bug in Open MPI (v1.5.4 and v1.5.5rc2) regarding to
> the
n MPI 1.4.5
(mpi_yield_when_idle=1) I get ~1.8us latencies.
Matthias
On Tuesday 28 February 2012 06:20:28 Christopher Samuel wrote:
> On 13/02/12 22:11, Matthias Jurenz wrote:
> > Do you have any idea? Please help!
>
> Do you see the same bad latency in the old branch (1.4.5) ?
>
> cheers,
> Chris
han actually available?
Matthias
On Tuesday 21 February 2012 17:17:49 Matthias Jurenz wrote:
> Some supplements:
>
> I tried several compilers for building Open MPI with enabled optimizations
> for the AMD Bulldozer architecture:
>
> * gcc 4.6.2 (-Ofast -mtune=bdver1 -march=bdver1)
Thanks for the hint!
This issue is fixed by r26042 (CMR #3037).
Matthias
On Friday 24 February 2012 05:24:26 Paul H. Hargrove wrote:
> This is consistent with my findings w/ XLC (mostly on BG/L and BG/P
> front end nodes).
> None of the 7.0, 8.0, 9.0 or 11.1 versions of XLC I tested could
> gen
without success.
Do you have any further ideas?
Matthias
On Monday 20 February 2012 13:46:54 Matthias Jurenz wrote:
> If the processes are bound for L2 sharing (i.e. using neighboring cores
> pu:0 and pu:1) I get the *worst* latency results:
>
> $ mpiexec -np 1 hwloc-bind pu:0 ./NPm
es 10 times --> 15.26 Mbps in 1.50 usec
3: 4 bytes 10 times --> 20.23 Mbps in 1.51 usec
So it seems that the process binding within Open MPI works and retires as
reason for the bad latency :-(
Matthias
On Thursday 16 February 2012 17:51:53 Brice G
Does that mean that the workaround I suggested (extra linkage of -lz) is not
needed anymore?
Matthias
On Friday 17 February 2012 16:15:16 Dmitri Gribenko wrote:
> Hi Jeff,
>
> On Fri, Feb 17, 2012 at 1:14 PM, Jeff Squyres wrote:
> > Are you compiling a nightly 1.7/trunk tarball, or an SVN chec
Actually, Libtool evaluates the dependencies of libotf.la where -lz should
appear:
$ cat otflib/libotf.la | grep dependency_libs
# Linker flags that can not go in dependency_libs.
dependency_libs=' -lz'
In base of that Libtool should add -lz to the linker command line, or not?
However, adding
Thanks for the hint, Brice.
I'll forward this bug report to our cluster vendor.
Could this be the reason for the bad latencies with Open MPI or does it only
affect hwloc/lstopo?
Matthias
On Thursday 16 February 2012 15:46:46 Brice Goglin wrote:
> Le 16/02/2012 15:39, Matthias Jurenz
On Thursday 16 February 2012 16:50:55 Jeff Squyres wrote:
> On Feb 16, 2012, at 10:30 AM, Matthias Jurenz wrote:
> > $ mpirun -np 2 --bind-to-core --cpus-per-proc 2 hwloc-bind --get
> > 0x0003
> > 0x000c
>
> That seems right. From your prior email, 3 maps to
On Thursday 16 February 2012 16:21:10 Jeff Squyres wrote:
> On Feb 16, 2012, at 9:39 AM, Matthias Jurenz wrote:
> > However, the latencies are constant now but still too high:
> >
> > $ mpirun -np 2 --bind-to-core --cpus-per-proc 2 ./NPmpi_ompi1.5.5 -S -u
> > 12
tep would be to download
> hwloc 1.3.2 and verify that lstopo is faithfully reporting the actual
> topology of your system. Can you do that?
>
> On Feb 16, 2012, at 7:06 AM, Matthias Jurenz wrote:
> > Jeff,
> >
> > sorry for the confusion - the all2all is a classic
LLTOALL, or a pingpong?
>
> FWIW, on an older Nehalem machine running NetPIPE/MPI, I'm getting about
> .27us latencies for short messages over sm and binding to socket.
>
> On Feb 14, 2012, at 7:20 AM, Matthias Jurenz wrote:
> > I've built Open MPI 1.5.5rc1 (tarball
I could reproduce the build error with Clang 2.9. Adding the operator< to
DefRec_BaseS fixes the problem, although this operator is not used.
Thanks for the hints!
I'll commit this fix and create a CMR to v1.5 soon.
Matthias
On Thursday 16 February 2012 04:22:33 Paul H. Hargrove wrote:
> Dmitr
ure option '--disable-weak-symbols'.
Jeff, what's your opinion?
Matthias
On Wednesday 15 February 2012 10:33:30 Paul Hargrove wrote:
> See responses mixed in below.
>
> On Wed, Feb 15, 2012 at 1:02 AM, Matthias Jurenz <
>
> matthias.jur...@tu-dresden.de> wrote
Unfortunately, we don't have access to a PPC system with MacOS 10.4 to try to
reproduce the error.
Paul, could you please check for the definition of the macro
OPAL_HAVE_WEAK_SYMBOLS in ompi_config.h? I assume that the ancient GNU compiler
on PPC/MacOS10.4 does not support weak-symbols which ca
cking mem
> > binding.
> >
> > Sent from my iPad
> >
> > On Feb 13, 2012, at 7:07 AM, Matthias Jurenz wrote:
> >> Hi Sylvain,
> >>
> >> thanks for the quick response!
> >>
> >> Here some results with enabled
lated to bad memory affinity.
>
> Try to launch pingpong on two CPUs of the same socket, then on different
> sockets (i.e. bind each process to a core, and try different
> configurations).
>
> Sylvain
>
>
>
> De :Matthias Jurenz
> A : Open MPI Developer
Hello all,
on our new AMD cluster (AMD Opteron 6274, 2,2GHz) we get very bad latencies
(~1.5us) when performing 0-byte p2p communication on one single node using the
Open MPI sm BTL. When using Platform MPI we get ~0.5us latencies which is
pretty good. The bandwidth results are similar for both
Thanks for the hint, Paul.
This build issue is fixed by CMR #2938.
Matthias
On Wednesday 14 December 2011 07:44:48 Paul H. Hargrove wrote:
> OK, Jeff probably wants to choke me for all these emails, but here comes
> another...
>
> I am now configuring my 5 BSD systems with "--without-hwloc
> --d
Hello,
this issue is fixed by r25595.
It seems to be a compiler bug in GCC v4.2.? ... When using assert() within
OpenMP-parallel regions the compiler prepends an extra '_' to the symbol
__buildin_expect(), so the linker reports undefined references.
The solution is actually a workaround where
Hi,
I've just made a clean checkout of the trunk and built it - I didn't see any
problems. Also the latest MTT test-builds look good.
Could you please re-checkout the trunk to have a clean working copy and try it
again?
Matthias
On Tuesday 22 November 2011 04:15:25 Ralph Castain wrote:
> Hi V
I'll look on it asap. Thanks for the hint, George!
Matthias
On Monday 14 November 2011 23:39:08 George Bosilca wrote:
> This is supposed to be an intrinsic, automatically replaced by GCC during
> the compilation process. If I do the same configure as you (on the same
> machine) I have in my opal_
x27;t turn VT off like I usually do.
>
> Any help would be appreciated.
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Matthias Jurenz
Technische Universität Dresden
Center for Information Services and H
not - it may break some other
functionality.
Matthias
On Friday 10 June 2011 15:29:08 Jeff Squyres wrote:
> On Jun 10, 2011, at 5:16 AM, Matthias Jurenz wrote:
> > There are different ways to fix the problem:
> >
> > 1. Apply the attached patch on ltmain.sh.
> >
>
It's a Libtool issue (once again) which occurs if a previous build is re-
configured without subsequent "make clean" and the LIBC developer library
"libutil" is added to LIBS.
The error is simple to reproduce by the following steps:
1. configure
2. make -C ompi/contrib/vt/vt/util
3. configure
or
+ attachment
On Friday 10 June 2011 12:00:49 you wrote:
> It's a Libtool issue (once again) which occurs if a previous build is re-
> configured without subsequent "make clean" and the LIBC developer library
> "libutil" is added to LIBS.
>
> The error is simple to reproduce by the following steps
It's a Libtool issue (once again) which occurs if a previous build is re-
configured without subsequent "make clean" and the LIBC developer library
"libutil" is added to LIBS.
The error is simple to reproduce by the following steps:
1. configure
2. make -C ompi/contrib/vt/vt/util
3. configure
or
Hello Paul,
the default option behavior of VT makes not sense in Open MPI, so it will be
disabled in v1.5[rc7].
Thanks for the hint!
Matthias
On Thursday 26 August 2010 06:13:31 Paul H. Hargrove wrote:
> I've encountered an interesting situation on Solaris/SPARC where Open
> MPI defaults to CC
On Saturday 14 August 2010 00:10:49 Lisandro Dalcin wrote:
> On 13 August 2010 05:22, Matthias Jurenz
wrote:
> > On Wednesday 11 August 2010 23:16:50 Lisandro Dalcin wrote:
> >> On 11 August 2010 03:12, Matthias Jurenz
> >
> > wrote:
> >> > Hello Li
On Wednesday 11 August 2010 23:16:50 Lisandro Dalcin wrote:
> On 11 August 2010 03:12, Matthias Jurenz
wrote:
> > Hello Lisandro,
> >
> > this problem will be fixed in the next Open MPI release. There was an
> > obsolete preprocessor condition around the MPI_Init
Hello Lisandro,
this problem will be fixed in the next Open MPI release. There was an obsolete
preprocessor condition around the MPI_Init_thread wrapper, so the source code
could never be compiled :-(
Thanks for the hint.
Matthias
On Wednesday 11 August 2010 05:34:33 Lisandro Dalcin wrote:
>
Hi Yaohui,
can you tell me the version of your gcc and g++ compiler?
It seems to me that your g++ compiler is older (<4.2) than your gcc compiler.
If that's true, then we have to enhance the VT configure, so that the
availability of '-fopenmp' for g++ will be tested.
Matthias
On Monday 05 Apri
Fixed! Thanks for this hint.
On Friday 19 March 2010 20:08:53 Terry Dontje wrote:
> I was trying to compile the trunk head using Linux and Sun Studio
> compilers and saw the following error. I am not sure that the compiler
> really is the smoking gun. I see that State.cpp was last modified in
>
r these changes to be pushed to the live site.
>
> Matthias Jurenz wrote:
>
> >Could you also mention the tool 'otfprofile' under the section 7,
> >please?
> >
> >On Tue, 2009-07-14 at 18:54 -0700, Eugene Loh wrote:
> >
> >
> >>P.S.
On Wed, 2009-07-15 at 10:24 -0400, Jeff Squyres wrote:
> On Jul 15, 2009, at 8:57 AM, Matthias Jurenz wrote:
>
> > I sent the answer directly to the user, 'cause I didn't subscribe to
> > the
> > user-list. I'll do that asap ;-)
> >
>
> Than
Hi Jeff,
On Wed, 2009-07-15 at 07:13 -0400, Jeff Squyres wrote:
> On Jul 15, 2009, at 6:17 AM, Matthias Jurenz wrote:
>
> > the FAQ page looks very nice.
> >
>
> Ditto -- thanks for doing it, Eugene!
>
> > I just sent the following answer to Lin Zou:
> >
MPI Analyzer, but I believe I've done so tastefully and
> appropriately! Throw tomatoes if you see fit.
>
> P.S. Until the page goes live, I'll also leave it at
> http://www.osl.iu.edu/~eloh/faq/?category=perftools . Or, check out a
> workspace.
> ____
-dresden.de/zih/vampirtrace. Please give it a try.
Regards,
Matthias Jurenz
On Mon, 2009-03-30 at 19:04 +0200, Leonardo Fialho wrote:
> Hi Jeff,
>
> There are...
>
> Thanks a lot,
> Leonardo
>
> Jeff Squyres escribió:
> > Can you send all the information listed here:
>
Unfortunately, I have no write access to the OFED bugzilla, so I answer
to the OMPI devel list...
It sounds like the following issue that we had early January:
http://www.open-mpi.org/community/lists/devel/2009/01/5102.php
The bottom line was that we don't know what's wrong.
However, there are
A workaround for this problem would be to change the selected timer
after configure in 'ompi/contrib/vt/vt/config.h'.
To do this, just replace the line
#define TIMER TIMER_CYCLE_COUNTER
by
#define TIMER TIMER_GETTIMEOFDAY
I agree with Paul - the correct solution would be to choose
ed, or is
> it just some coding style that these particular flags don't like?
>
>
> On Jan 14, 2009, at 5:05 AM, Matthias Jurenz wrote:
>
> > Another workaround should be to disable the I/O tracing feature of VT
> > by adding the configure option
> &
Another workaround should be to disable the I/O tracing feature of VT
by adding the configure option
'--with-contrib-vt-flags=--disable-iotrace'
That will have the effect that the upcoming OMPI-rpm's have no support
for I/O tracing, but in our opinion it is not so bad...
Furthermore, we
PM, Jeff Squyres wrote:
>
> > Done (for my upcoming commit with this stuff).
> >
> > Thanks!
> >
> > On Oct 29, 2008, at 12:05 PM, Matthias Jurenz wrote:
> >
> >> On Mi, 2008-10-29 at 08:43 -0400, Jeff Squyres wrote:
> >>>
> >>>
On Mi, 2008-10-29 at 08:43 -0400, Jeff Squyres wrote:
> On Oct 29, 2008, at 8:14 AM, Matthias Jurenz wrote:
>
> > The problem should be fixed in the trunk. VampirTrace also comes now
> > with an own
> > implementation of 'snprintf'. More precisely, the corres
On Mi, 2008-10-29 at 08:43 -0400, Jeff Squyres wrote:
> On Oct 29, 2008, at 8:14 AM, Matthias Jurenz wrote:
>
> > The problem should be fixed in the trunk. VampirTrace also comes now
> > with an own
> > implementation of 'snprintf'. More precisely, the corres
> > --- orte/tools/orte-iof/orte-iof.c (revision 19808)
> > +++ orte/tools/orte-iof/orte-iof.c (working copy)
> > @@ -37,6 +37,9 @@
> > #ifdef HAVE_STDLIB_H
> > #include
> > #endif /* HAVE_STDLIB_H */
> > +#ifdef HAVE_SIGNAL_H
> > +#include
>
uot;
of the HCA parameter file. Is that correct?
Matthias
--
Matthias Jurenz,
Center for Information Services and
High Performance Computing (ZIH), TU Dresden,
Willersbau A106, Zellescher Weg 12, 01062 Dresden
phone +49-351-463-31945, fax +49-351-463-37773
smime.p7s
Description: S/MIME cryptographic signature
> Ralf
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
--
Matthias Jurenz,
Center for Information Services and
High Performance Computing (ZIH), TU Dresden,
Willersbau A106, Ze
uff is incorporated into OMPI's autogen stuff
> and we don't have timestamp issues that can cause re-autoconfs/etc.,
> we can re-enable it by default.
>
> Dresden: any estimates on when the integration will occur?
>
--
Matthias Jurenz,
Center for Information Services an
default everything
> should be fine.
>
> Therefore, I'd like to keep it enabled by default ... well, of course I
> would ;)
>
> Are there any other isses open with VT config?
>
> Andreas
>
>
--
Matthias Jurenz,
Center for Information Services and
High Perf
Thanks for the hint, Ralf ! I will give it a try...
On Mi, 2008-02-13 at 13:58 +0100, Ralf Wildenhues wrote:
> Hallo Matthias,
>
> * Matthias Jurenz wrote on Wed, Feb 13, 2008 at 01:49:41PM CET:
> > On Di, 2008-02-12 at 11:27 -0500, George Bosilca wrote:
> >
> > >
' instead.
> tools/opari/tool/Makefile.am:11: `LDFLAGS' is a user variable, you
> should not override it;
> tools/opari/tool/Makefile.am:11: use `AM_LDFLAGS' instead.
>
>Thanks,
> george.
>
> ___
>
t 01:08:32PM +0100, Matthias Jurenz wrote:
> > Hi Gleb,
> >
> > that's very strange... cause' the corresponding 'Makefile.in' is
> > definitely not empty (checked in to the SVN repository).
> Ah, here is the problem. Makefile.in is empty in my tree.
;
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory `/home_local/glebn/build_dbg/ompi'
> make: *** [install-recursive] Error 1
>
> ompi/contrib/vt/vt/Makefile is empty!
> --
> Gleb.
> ____
configure.m4])
> +OMPI_CONTRIB_DIST_SUBDIRS="$OMPI_CONTRIB_DIST_SUBDIRS
> contrib/software"
> +_OMPI_CONTRIB_CONFIGURE(software)])
>
> # Setup the top-level glue
> AC_SUBST(OMPI_CONTRIB_SUBDIRS)
> __
acefilter.o(.text+0x577b): In function `__ompdo_main2':
> /home/jsquyres/svn/ompi2/ompi/contrib/vt/vt/tools/vtfilter/
> vt_tracefilter.cc:802: undefined reference to
> `FiltHandlerArgument::FiltHandlerArgument(FiltHandlerArgument const&)'
> collect2: ld returned 1 exit status
>
ibvt.ompi: for hybrid applications (MPI and OpenMP)
> Cheers,
> Ralf
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
--
Matthias Jurenz,
Center for Information Services and
Hig
-functions
> -fno-strict-aliasing -pthread FFLAGS= --no-create --no-recursion
> checking build system type... x86_64-unknown-linux-gnu
>
>
>
> Not sure if this is expected behavior, but it seems wrong to me.
>
> Thanks,
>
> Tim
>
> Matthias Jurenz wrote:
&g
lds, we separate
> the stdout and stderr into 2 streams. So you kinda have to merge them
> in your head; sorry...
>
--
Matthias Jurenz,
Center for Information Services and
High Performance Computing (ZIH), TU Dresden,
Willersbau A106, Zellescher Weg 12, 01062 Dresden
phone +49-3
gt; >> collect2: ld returned 1 exit status
> >> make[5]: *** [vtfilter] Error 1
> >>
> >>george.
> >>
> >
> > this issue should be fixed now, even without additional configure
> > parameters.
> >
> >
> >
>
ies. A static build
> > will fails if libz.a is not installed on the system.
> >
> > /usr/bin/ld: cannot find -lz
> > collect2: ld returned 1 exit status
> > make[5]: *** [vtfilter] Error 1
> >
> > george.
> >
> > On Jan 28, 2008, at 12:37 PM
> >
> > Just my $0.02
> >
> > --
> > Cluster and Metacomputing Working Group
> > Friedrich-Schiller-Universität Jena, Germany
> >
> > private: http://adi.thur.de
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
--
Matthias Jurenz,
Center for Information Services and
High Performance Computing (ZIH), TU Dresden,
Willersbau A106, Zellescher Weg 12, 01062 Dresden
phone +49-351-463-31945, fax +49-351-463-37773
smime.p7s
Description: S/MIME cryptographic signature
> vtunify: Error: Could not open file ./a.1.uctl
> [13:14] beezle:~/tmp/foo %
>
> Yoinks -- an assertion failure...
>
> Successive runs seems to be variations on these errors (the assertion
> failure and various "could not open" and "could not remove" err
gure --prefix=/Users/jsquyres/bogus CC=/usr/bin/gcc CXX=/usr/
> bin/g++ --disable-mpi-fortran
>
> However, the hpc.sf.net OS X compilers are not uncommon (because they
> provide fortran compiler support for OS X). Do you think you'll be
> able to test with these co
80 matches
Mail list logo
